aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* kernel: bump 5.10 to 5.10.75Rui Salvaterra2021-10-2117-65/+22
| | | | | | | | | Deleted (upstreamed): bcm27xx/patches-5.10/950-0735-xhci-guard-accesses-to-ep_state-in-xhci_endpoint_res.patch [1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=dc3e0a20dbb9dbaa22f4a33dea34230f8c663c40 Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* kernel: bump 5.10 to 5.10.74Rui Salvaterra2021-10-2117-17/+17
| | | | | | Patches automatically refreshed. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* kernel: bump 5.10 to 5.10.73Rui Salvaterra2021-10-212-18/+5
| | | | | | Patches automatically refreshed. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* kernel: bump 5.4 to 5.4.155John Audia2021-10-218-13/+13
| | | | | | All patches automatically rebased. Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.4 to 5.4.154John Audia2021-10-2122-22/+22
| | | | | | All patches automatically rebased. Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.4 to 5.4.153John Audia2021-10-2125-1699/+49
| | | | | | | | | Removed upstreamed: backport-5.4/070-v5.5-MIPS-BPF-Restore-MIPS32-cBPF-JIT.patch All other patches automatically rebased. Signed-off-by: John Audia <graysky@archlinux.us>
* realtek: switch to kernel 5.10Adrian Schmutzler2021-10-201-2/+1
| | | | | | | The usual testers did their tests. Now we need testers who use the master builds. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* tegra: switch to kernel 5.10Adrian Schmutzler2021-10-181-2/+1
| | | | | | | | This target has testing support for kernel 5.10 for four months now. Time to switch the default. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Acked-by: Tomasz Maciej Nowak <tmn505@gmail.com>
* bcm53xx: enable Linksys EA6300 & EA9200 buildsRafał Miłecki2021-10-181-3/+0
| | | | | | | | | | Both should be supported since: 1. Adding NVMEM driver for NVRAM 2. Using NVRAM info for determining active firmware partition Linksys EA9500 uses very similar design and works fine. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* ramips: remove kmod-mt7663-firmware-sta from device packagesFelix Fietkau2021-10-171-3/+3
| | | | | | | | This firmware should only be used for mobile devices (e.g. laptops), where AP mode functionality is typically not used. This firmware supports a lot of power saving offload functionality at the expense of AP mode support. Signed-off-by: Felix Fietkau <nbd@nbd.name>
* ramips: fix dtc warnings for telco-electronics_x1Rosen Penev2021-10-171-16/+17
| | | | | | | In all other dts files, the entire block is not edited like this. They're edited separately. Signed-off-by: Rosen Penev <rosenp@gmail.com>
* zynq: switch to kernel 5.10Luis Araneda2021-10-171-1/+1
| | | | | | | | | Use kernel 5.10 by default compile-tested: all devices from target (wth ALL_KMODS) run-tested: Digilent Zybo Z7-20 Signed-off-by: Luis Araneda <luaraneda@gmail.com>
* zynq: kernel: update config for 5.10Luis Araneda2021-10-171-11/+13
| | | | | | Update config with make kernel_oldconfig Signed-off-by: Luis Araneda <luaraneda@gmail.com>
* zynq: kernel: copy config from 5.4 to 5.10Luis Araneda2021-10-171-0/+550
| | | | Signed-off-by: Luis Araneda <luaraneda@gmail.com>
* zynq: kernel: remove wireless extensions symbolsLuis Araneda2021-10-171-3/+0
| | | | | | | | | | | | This fixes compilation of several wireless drivers that require support for the old wireless extension to work. One example is kmod-hermes. The symbols are set to "y" on generic configuration. But they were wrongly disabled on the target-specific configuration. Signed-off-by: Luis Araneda <luaraneda@gmail.com>
* zynq: kernel: refresh configLuis Araneda2021-10-171-94/+2
| | | | | | | | using "make kernel_oldconfig" Several configs are now part of generic Signed-off-by: Luis Araneda <luaraneda@gmail.com>
* mediatek: add EEPROM data for BPi-R64 2.4GHz wmacDaniel Golle2021-10-151-0/+31
| | | | | | | | | | | EEPROM data extracted from vendor image found at http://forum.banana-pi.org/t/bpi-r64-mt7622-mac80211-wifi-driver/10246/77 http://forum.banana-pi.org/uploads/short-url/jworbyBYpvrw9VQ2sx92B9z6DWS.bin MAC address in the EEPROM has been zero'd which results in random address on boot. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* kernel: backport a rewrite of the mips eBPF JIT implementationFelix Fietkau2021-10-1422-10/+9497
| | | | | | | This adds support for eBPF JIT for 32 bit targets and significantly improves correctness. Signed-off-by: Felix Fietkau <nbd@nbd.name>
* x86/64: enable MMIO_CMDLINE_DEVICES for firecracker supportPaul Spooren2021-10-121-0/+1
| | | | | | | | | | | | | This Kernel option allows to run OpenWrt witin a `firecracker` micro VM. Firecracker is a KVM-based tool for superfast booting VMs on x86_64 and aarch64. It makes rootfs available to the guest as a virtio-mmio device and passes its address via the kernel cmdline. A kernel without CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES will not recognize the rootfs virtio-mmio device. Suggested-by: Packet Please <pktpls@systemli.org> Signed-off-by: Paul Spooren <mail@aparcar.org>
* armvirt: enable MMIO_CMDLINE_DEVICES for firecracker supportPaul Spooren2021-10-121-0/+1
| | | | | | | | | | | | | This Kernel option allows to run OpenWrt witin a `firecracker` micro VM. Firecracker is a KVM-based tool for superfast booting VMs on x86_64 and aarch64. It makes rootfs available to the guest as a virtio-mmio device and passes its address via the kernel cmdline. A kernel without CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES will not recognize the rootfs virtio-mmio device. Suggested-by: Packet Please <pktpls@systemli.org> Signed-off-by: Paul Spooren <mail@aparcar.org>
* Revert "gpio-cdev: add nu801 userspace driver"Christian Lamparter2021-10-102-2/+2
| | | | | | | | | | | This reverts commit f536f5ebddd9c532a08ac4a9be3ef0c02f7bfeb8. As Hauke commented, this causes builder failures on 5.4 kernels. This revert includes changes to the mx100 kernel modules dependency as well as the uci led definitions. Tested-by: Chris Blake <chrisrblake93@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* ipq40xx: use zImage for GL.iNet GL-B1300, GL-S1300 to shrink below 4096kSzabolcs Hubai2021-10-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In the "ipq40xx: switch to Kernel 5.10" discussion at GitHub, Adrian noted [0] that these GL.iNet Conexa series devices, GL-B1300 and GL-S1300 failed their image generation [1] as their gzipped uImage kernel went above 4096k. While notifying the vendor about this problem [2], I tested all U-Boot releases from GL.iNet: - they really fail to boot kernel above 4096k - they don't support lzma: "Unimplemented compression type 3" - but they boot zImage Using zImage (xz compression) the kernel is 2909k which is more than a megabyte away from the KERNEL_SIZE := 4096k limit. The gzip compressed version would be 4116k. [0]: https://github.com/openwrt/openwrt/pull/4620#issuecomment-932765776 [1]: commit 7b1fa276f5a2 ("ipq40xx: add testing support for kernel 5.10") [2]: https://forum.gl-inet.com/t/ipq40xx-kernel-size-and-u-boot-v5-10-is-too-big-for-4-mb/17619 Signed-off-by: Szabolcs Hubai <szab.hu@gmail.com>
* x86: add support for Meraki MX100Chris Blake2021-10-106-0/+369
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit will add support for the Meraki MX100 in OpenWRT. Specs: * CPU: Intel Xeon E3-1200 Series 1.5GHz 2C/4T * Memory: 4GB DDR3 1600 ECC * Storage: 1GB USB NAND, 1TB SATA HDD * Wireless: None * Wired: 10x 1Gb RJ45, 2x 1Gb SFP UART: The UART header is named CONN11 and is found in the center of the mainboard. The pinout from Pin 1 (marked with a black triangle) to pin 4 is below: Pin 1: VCC Pin 2: TX Pin 3: RX Pin 4: GND Note that VCC is not required for UART on this device. Booting: 1. Flash/burn one of the images from this repo to a flash drive. 2. Take the top off the MX100, and unplug the SATA cable from the HDD. 3. Hook up UART to the MX100, plug in the USB drive, and then power up the device. 4. At the BIOS prompt, quickly press F7 and then scroll to the Save & Exit tab. 5. Scroll down to Boot Override, and select the UEFI entry for your jumpdrive. Note: UEFI booting will fail if the SATA cable for the HDD is plugged in. The issue is explained under the Flashing instructions. Flashing: 1. Ensure the MX100 is powered down, and not plugged into power. 2. Take the top off the MX100, and unplug the SATA cable from the HDD. 3. Using the Mini USB female port found by the SATA port on the motherboard, flash one of the images to the system. Example: `dd if=image of=/dev/sdb conv=fdatasync` where sdb is the USB device for the MX100's NAND. 4. Unplug the Mini USB, hook up UART to the MX100, and then power up the device. 5. At the BIOS prompt, quickly press F7 and then scroll to the Boot tab. 6. Change the boot order and set UEFI: USB DISK 2.0 as first, and USB DISK 2.0 as second. Disable the other boot options. 7. Go to Save & Exit, and then select Save Changes and Reset Note that OpenWRT will fail to boot in UEFI mode when the SATA hard drive is plugged in. To fix this, boot with the SATA disk unplugged and then run the following command: `sed -i "s|hd0,gpt1|hd1,gpt1|g" boot/grub/grub.cfg` Once the above is ran, OpenWRT will boot when the HDD is plugged into SATA. The reason this happens is the UEFI implementation for the MX100 will always set anything on SATA to HD0 instead of the onboard USB storage, so we have to accomidate it since OpenWRT's GRUB does not support detecting a boot disk via UUID. Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
* apm821xx: disable and move kernel CONFIG_ symbolsChristian Lamparter2021-10-102-31/+17
| | | | | | | | | | | | | | | | | try to reduce the kernel size by disabling and moving options from the common kernel configuration to the SATA target that doesn't have the constraints. For NAND this has become necessary because as with 5.10 some devices outgrew their kernels. Though, in my tests this didn't help much: just a smidgen over 100kib was saved on the uncompressed kernel. ... running make kernel_oldconfig also removed some other config symbols, mostly those that already set from elsewhere or became obsolete in the meantime. Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* apm821xx: disable MX60(W) due to kernel sizeChristian Lamparter2021-10-101-0/+1
| | | | | | | | disables the MX60(W) from being built by the builders for now. But there's an effort to bring it back: <https://github.com/openwrt/openwrt/pull/4617> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* gemini: splash banner on framebuffer consoleLinus Walleij2021-10-101-0/+9
| | | | | | | | | The D-Link DIR-685 has a small screen with a framebuffer console, so if we have this, when we start, display the banner on this framebuffer console so the user know they are running OpenWRT as root filesystem. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* apm821xx: WNDAP620 + WNDAP660: reorganize partitions for 5.10Christian Lamparter2021-10-102-6/+9
| | | | | | | | | | | | | | | | | | | | | | Due to 5.10 increased kernel size, the current 4MiB-ish kernel partition got too small. Luckily, netgear's uboot environment is setup to read 0x60000 bytes from the kernel partition location. ... While at it: also do some cleanups in the DTS in there. The original (re-)installation described in commit d82d84694e60 ("apm821xx: add support for the Netgear WNDAP620 and WNDAP660") seemed to be still working for now. What I noticed though is that the bigger initramfs images needed to use a different destination address (1000000) to prevent it overwriting itself during decompression. i.e: # tftp 1000000 openwrt-...-wndap620-initramfs-kernel.bin # bootm However, in case of the WNDAP620+660 the factory.img image can be written directly to the flash through uboot. Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* apm821xx: switch to Kernel 5.10Paul Spooren2021-10-101-2/+1
| | | | Signed-off-by: Paul Spooren <mail@aparcar.org>
* apm821xx: move CONFIG_DMA* to the generic apm821xx configChristian Lamparter2021-10-103-31/+8
| | | | | | | | | | | | Both NAND and SATA targets need the DMA engine in one way or another. Due to a kernel config refresh various existing symbols got removed from the apm821xx main config file as well. (That being said, they are still included because the built-in crpyto4xx depends on these.) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* kernel: bump 5.4 to 5.4.152John Audia2021-10-101-5/+5
| | | | | | All patches automatically rebased. Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.4 to 5.4.151John Audia2021-10-103-9/+9
| | | | | | All patches automatically rebased. Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.10 to 5.10.72John Audia2021-10-106-21/+21
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: bcm2711/RPi4B Run-tested: bcm2711/RPi4B Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.10 to 5.10.71John Audia2021-10-1011-20/+20
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: bcm2711/RPi4B, ipq806x/R7800 Run-tested: bcm2711/RPi4B, ipq806x/R7800 Signed-off-by: John Audia <graysky@archlinux.us>
* rockchip: rename "Rock Pi 4" to "Rock Pi 4A"Adrian Schmutzler2021-10-103-33/+4
| | | | | | | | | | | | Kernel has added the different variants of the Rock Pi 4 in commit b5edb0467370 ("arm64: dts: rockchip: Mark rock-pi-4 as rock-pi-4a dts"). The former Rock Pi 4 is now Rock Pi 4A. For compatibility with kernel 5.4, this rename has been held back so far. Having switched to kernel 5.10 now, we can finally apply it in our tree as well. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* rockchip: switch to kernel 5.10Adrian Schmutzler2021-10-101-2/+1
| | | | | | | This target has testing support for more than half a year now. Time to switch. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* kernel: drop support for mtd-mac-addressAnsuel Smith2021-10-096-228/+16
| | | | | | | | Now that we have fully switched to nvmem interface we can drop the use of mtd-mac-address patches as it's not used anymore and the new nvmem implementation should be used for any new device. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
* mvebu: mochabin: correct LED labels in DTSRobert Marko2021-10-091-9/+9
| | | | | | | | | | LED labels got reversed by accident, so fix it to the usual color:led_name format. Fixes: 78cf3e53b1f4 ("mvebu: add Globalscale MOCHAbin") Signed-off-by: Robert Marko <robert.marko@sartura.hr> [add Fixes:] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* kirkwood: switch to kernel 5.10Adrian Schmutzler2021-10-091-2/+1
| | | | | | | This target has testing support for more than half a year now. Time to switch. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* oxnas: switch to Linux 5.10Daniel Golle2021-10-0913-1356/+1
| | | | | | | Linux 5.10 has been there as testing kernel for a while now. Do the switch and drop config and patches for Linux 5.4. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mediatek: enable configfs for DT overlay on mt7622 and mt7623Daniel Golle2021-10-092-0/+5
| | | | | | | | | Enable kernel options to allow loading device tree overlay via configfs at runtime. This is useful for devboards like the BPi-R2 and BPi-R64 which got RasbPi-compatible 40-pin GPIO header which allow all sorts of extensions. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* realtek: add legacy realtek GPIO driver for rtl9300 supportBirger Koblitz2021-10-094-0/+507
| | | | | | | The otto GPIO driver does not work with rtl9300 SoCs. Add the legacy driver again and use that by default in the 9300 .dtsi Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: enable Aquantia PHY supportBirger Koblitz2021-10-091-0/+1
| | | | | | Enables Aquantia PHY support in the kernel Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: Fix bug when accessing external PHYs on SoCs older than Revision CBirger Koblitz2021-10-091-3/+22
| | | | | | | | | | RTL8393 SoCs older than Revision C hang on accesses to PHYs with PHY address larger or equal to the CPU-port (52). This will make scanning the MDIO bus hang forever. Since the RTL8390 platform does not support more than 52 PHYs, return -EIO for phy addresses >= 52. Note that the RTL8390 family of SoCs has a fixed mapping between port number and PHY-address. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: cleanup PHY driverBirger Koblitz2021-10-091-8/+6
| | | | | | Removes unnecessary output from the RTL PHY drivers. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: Add debugfs support for RTL9300Birger Koblitz2021-10-092-1/+130
| | | | | | Adds support for debugfs on RTL9300, in particular the drop counters. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: Add SoC-specific routing offload implementationBirger Koblitz2021-10-094-165/+938
| | | | | | | | Adds SoC specific routing offload implementations for RTL8380/90 and RTL9300. RTL83xx supports merely nexthop routing, RTL9300 full host and prefix routes. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: add driver support for routing offloadBirger Koblitz2021-10-092-20/+946
| | | | | | | | Add generic support for listening to FIB and Event notifier updates and use this information to hook into the L3 hardware capabilities of the RTL SoCs. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* kernel: Add AQR113C and AQR813 supportBirger Koblitz2021-10-091-0/+142
| | | | | | | This hack adds support for the Aquantia 4th generation, 10GBit PHYs AQR113C and AQR813. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: Improve MDIO bus probing for RTL9300Birger Koblitz2021-10-091-21/+11
| | | | | | | Improve handling of multi-gig ports on the RTL9300 when probing the MDIO bus. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: Fix bug in VLAN ingress and egress filteringBirger Koblitz2021-10-091-4/+4
| | | | | | | | | | | The ingress filter registers use 2 bits for each port to define the filtering state, whereas the egress filter uses 1 bit. So for for the ingress filter the register offset for a given port is: (port >> 4) << 4: since there are 16 entries in a register of 32 bits and for the egress filter: (port >> 5) << 4: since there are 32 entries in a register of 32 bits Signed-off-by: Birger Koblitz <git@birger-koblitz.de>