aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* apm821xx: implement new LED label naming schemeChristian Lamparter2021-10-2210-122/+273
| | | | | | | | | | | | | | | | | | | | | | | This patch updates all current APM82181 devices over to that "new LED naming scheme". This includes many updates to the device-tree: - dropped the deprecated, but beloved "label" property. - rename all DT leds node names to led-#. - add function and color properties. - utilized panic-indicator property. - dropped led- aliases (see below). migration scripts for all devices are included. For more information. See: <https://www.kernel.org/doc/html/latest/leds/leds-class.html> For the future: It looks like the color+function properties won over the dt-alias / label. This will need to be wired up into openwrt eventually. For APM821xx the situation is that all devices have a dedicated power and fault indicator. Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* ath79: lzma-loader: fix & re-enable per-board CONFIG_BOARD_DEVChristian Lamparter2021-10-221-2/+5
| | | | | | | | | | | | | | | | | | | Back in the AR71XX days, the lzma-loader code could be customized based on the $BOARD variable. These would be passed as a compile-time -DCONFIG_BOARD_$DEVICE_MODEL flag to the compiler. Hence, the lzma-loader would be able to include device-specific fixups. Note: There's still a fixup for the TpLink TL-WR1043ND V1 found in the lzma-loader's board.c code. But since the days of AR71XX I couldn't find a forum post or bug reported. So, I left it as is to not break anything by enabling it. => If you have a TL-WR1043ND V1 and you have problem with the ethernet: let me know. Because otherwise, the fixup might simply no longer needed with ath79 and it can be removed. Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* apm821xx: MX60(W): re-enable + allow bigger future kernelsChristian Lamparter2021-10-222-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MX60's kernel is limited to 0x3EFC00 by the values in mkmerakifw.c. Since the initramfs method of loading the kernel seems to be working, this patch does away with the use of the mkmerakifw tool for the MX60(W). But this will go along with a change in u-boot as well. So before you upgrade, please attach the serial cable and perform: | setenv owrt510_boot run meraki_ubi owrt_bootargs\; run owrt_load1 owrt_bootkernel\; run owrt_load2 owrt_bootkernel | setenv bootcmd run owrt510_boot | saveenv Note: You won't be able to use older OpenWrt releases without switching the bootcmd back to owrt_boot! Note2: We are no longer compatible with older OpenWrt MX60 installs. the legacy BOARD_NAME and SUPPORTED_DEVICES can be dropped. This is because upgrades from older images are not possible without uboot env changes anymore. Also the bogus BLOCKSIZE value (which was set to 63k back then, in order to get the kernel properly aligned after the fdt + meraki header) can be set to the NANDs real value. The FDT size (which was needed for alignment) can now be slimmed down as well. Co-developed-by: Martin Kennedy <hurricos@gmail.com> Signed-off-by: Martin Kennedy <hurricos@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* apm821xx: MBL: HDD regulators overhaul for MBL DUOChristian Lamparter2021-10-221-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Takimata reported on the OpenWrt forum in thread [0], that his MyBook Live Duo wasn't booting OpenWrt 21.02 after upgrading from the previous OpenWrt 19.07. The last logged entries on his console |[ 0.531599] sata1-regulator GPIO handle specifies active low - ignored |[ 0.538391] sata0-regulator GPIO handle specifies active low - ignored |[ 0.759791] ata2: SATA link down (SStatus 0 SControl 300) |[ 0.765251] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) |[ 5.909555] ata1.00: qc timeout (cmd 0xec) |[ 5.913656] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) |[ 6.231757] ata1: SATA link down (SStatus 0 SControl 300) This extract clearly showed that the HDD on which OpenWrt is installed, simply disappeared after the SATA power regulators had been initialized. The reason why this worked with OpenWrt 19.07 was because the kernel config symbol CONFIG_REGULATOR=y was not set in the target's config-4.14. (This shows that the MBL Single does differ from the DUO in that it does not have programmable power regulators for the HDDs.) [0] <https://forum.openwrt.org/t/21-02-0-and-snapshot-fail-to-boot-on-my-book-live-duo/106585> Reported-by: Takimata (forum) Tested-by: Takimata (forum) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* ath79: mikrotik: use 64 KiB SPI NOR erase sectorsRoger Pueyo Centelles2021-10-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes CONFIG_MTD_SPI_NOR_USE_4K_SECTORS from the default symbols for the ath79/mikrotik target. MikroTik devices hold some of their user-configurable settings in the soft_config partition, which is typically sized 4 KiB, of the SPI NOR flash memory. Previously, in the ar71xx target, it was possible to use 64 KiB erase sectors but also smaller 4 KiB ones when needed. This is no longer the case in ath79 with newer kernels so, to be able to write to these 4 KiB small partitions without erasing 60 KiB around, the CONFIG_MTD_SPI_NOR_USE_4K_SECTORS symbol was added to the defaults. However, this ended up making sysupgrade images which were built with 64 KiB size blocks not to keep settings (e.g., the files under /etc/config/) over the flashing process. Using 4 KiB erase sector size on the sysupgrade images (by setting BLOCKSIZE = 4k) allows keeping settings over a flashing process, but renders the process terribly slow, possibly causing a user to mistakenly force a manual device reboot while the process is still on- going. Instead, ditching the 4 KiB erase sectors for the default 64 KiB erase size provides normal SPI write speed and sysupgrade times, at the expense of not being able to modify the soft_config partition (which is rarely a required thing). An OpenWrt patch for MTD_SPI_NOR_USE_4K_SECTORS_LIMIT may once have allowed to use different per-partition erase sector sizes. Due to changes on recent kernels it now only works on a per-device basis. Also, partial eraseblock write can be performed in ath79 with kernels 5.4 and lower, by copying the blocks from the 64 KiB, erasing the whole sector and restoring those blocks not meant to be modified. A kernel bump had that patch broken for a long time, but got fixed in bf2870c. Note: the settings in the soft_config partition can be reset to their defaults by holding the reset button for 5 seconds (and less than 10 seconds) at device boot. Fixes: FS#3492 (sysupgrade […] loses settings...) Fixes: a66eee63368e (ath79: add mikrotik subtarget) Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
* bcm53xx: bridge all LAN ports on Linksys EA9500Rafał Miłecki2021-10-221-1/+1
| | | | | | External switch ports need to be bridged too. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* bcm53xx: switch to the upstream DSA-based b53 driverRafał Miłecki2021-10-215-77/+49
| | | | | | | | | | 1. Drop swconfig 2. Simplify network setup 3. Verify network config 4. Disable Buffalo WZR-900DHP for now - it misses ports definition Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-By: Christian Lamparter <chunkeey@gmail.com>
* bcm47xx: add kernel 5.10 supportRafał Miłecki2021-10-2121-1/+2295
| | | | | | | It's for *development* only as it doesn't work with lzma-loader due to bigger size. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* ath79: use correct USB package for DIR-505David Bauer2021-10-211-1/+1
| | | | | | | AR9331 requires kmod-usb2-chipidea to use the USB ports. Include the correct package so they can be used with the base image. Signed-off-by: David Bauer <mail@david-bauer.net>
* kernel: 5.10: backport Marvell 88E1510/2 PHY SFP supportRobert Marko2021-10-212-0/+710
| | | | | | | | | | | | | Backport upstream SFP support for the Marvell 88E1510/2 PHY-s. Globalscale MOCHAbin uses this PHY for the hybrid WAN port that has 1G SFP and 1G RJ45 with PoE PD connected to it. This allows the SFP port to be used on it as well as parsing the SFP module details with ethtool. Signed-off-by: Robert Marko <robert.marko@sartura.hr>
* kernel: 5.10: backport 100 BaseX SFP supportRobert Marko2021-10-213-1/+97
| | | | | | | | | | Backport upstream support for 100Base-FX, 100Base-LX, 100Base-PX and 100Base-BX10 SFP modules. This is a prerequisite for the Globalscale MOCHAbin hybrid 1G SFP/Copper support backporting. Signed-off-by: Robert Marko <robert.marko@sartura.hr>
* 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>