aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* kernel: bump 5.4 to 5.4.141John Audia2021-08-214-4/+4
| | | | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Run-tested: ipq806x/R7800 No dmesg regressions, everything functional Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.10 to 5.10.60Rui Salvaterra2021-08-214-6/+6
| | | | | | No deleted or manually refreshed patches. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* mediatek: mt7623: enable more hardware featuresDaniel Golle2021-08-214-15/+118
| | | | | | | In order to make HDMI console available on the BananaPi BPi-R2 select various Kconfig symbols which are useful for systems with graphics. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* kernel: Do not deactivate staging driversHauke Mehrtens2021-08-216-6/+0
| | | | | | | | | Do not deactivate the kernel configuration symbol CONFIG_STAGING in the target configurations any more. This prevented the build of the exfat.ko for example. Fixes: FS#3979 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* layerscape: Do not activate ext2 and ext3 driver optionsHauke Mehrtens2021-08-211-6/+0
| | | | | | | | The ext3 driver was already removed, the kernel config options are only there for backwards compatibility. The eth4 driver takes care of ext3 file systems. The ext4 driver also handled ext2 file systems. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* archs38: Do not activate ext3 driver optionsHauke Mehrtens2021-08-211-3/+0
| | | | | | | | The ext3 driver was already removed, the kernel config options are only there for backwards compatibility. The eth4 driver takes care of ext3 file systems. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* mediatek: convert mtd-mac-address to nvmem for MT7629 RFBAdrian Schmutzler2021-08-207-24/+70
| | | | | | | This conversion appears to have been overlooked since it's in a kernel patch. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* lantiq: convert mtd-mac-address to nvmem for Fritz!Box 736xAdrian Schmutzler2021-08-204-5/+48
| | | | | | | Convert this series by moving the definitions to the individual devices. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: convert mtd-mac-address to nvmem for UniElec devicesAdrian Schmutzler2021-08-207-18/+80
| | | | | | | | | Convert this series by moving the definitions to the individual devices. Now all devices on ramips are converted. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: remove redundant nvmem definitionsAdrian Schmutzler2021-08-2020-172/+22
| | | | | | | | | Due to use of a script when migrating from mtd-mac-address, a few of the definitions are redundant in DTSI and DTS files. Remove those and consolidate the definitions in parent DTSI files in a few cases. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: remove redundant nvmem definitionsAdrian Schmutzler2021-08-2017-170/+0
| | | | | | | | Due to use of a script when migrating from mtd-mac-address, a few of the definitions are redundant in DTSI and DTS files. Remove those. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: fix indent in DTS for GL.iNet VIXMINI/microuter-N300Adrian Schmutzler2021-08-202-2/+2
| | | | | | Use correct indent. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: convert mtd-mac-address to nvmem for D-Link DIR-8xxAdrian Schmutzler2021-08-208-13/+137
| | | | | | | Convert this series by moving the definitions to the individual devices. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: convert remaining mtd-mac-address cases to nvmemAdrian Schmutzler2021-08-1864-157/+1406
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the nvmem-based approach for retrieving MAC addresses appears to depend on the addresses being set up after the partitions, it is no longer possible to keep the MAC address setup in shared DTSI files while the partitions itself are set up in DTS files for the individual devices. In ath79 the firmware partition is typically located somewhere "in the middle" of the partition table. Thus, it's not trivial to share the partitions containing MAC address information in a common DTSI (like we did in some cases on ramips). In this commit, MAC address setup is thus moved to the relevant partitions, and in most cases needs to be duplicated. While the duplication is not really nice, it eventually provides a cleaner and more tidy setup, making the DTS(I) file fragmentation a bit more logical. This should also help with adding new devices, as information is distributed across less locations. For consistency, this commit also moves the mtd-cal-data property "down" together with the MAC address setup, so it's not based on a partition before the latter is defined either. (This is only done for those files touched due to nvmem conversion.) Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: convert most mtd-mac-address cases in DTSI to nvmemAdrian Schmutzler2021-08-1847-1021/+938
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert most of the cases from mtd-mac-address to nvmem where MAC addresses are set in the DTSI, but the partitions are only located in the device DTS. This posed some problems earlier, since in these cases we are using partitions before they are defined, and the nvmem system did not seem to like that. There have been a few different resolution approaches, based on the different tradeoffs of deduplication vs. maintainability: 1. In many cases, the partition tables were identical except for the firmware partition size, and the firmware partition was the last in the table. In these cases, the partition table has been moved to the DTSI, and only the firmware partition's "reg" property has been kept in the DTS files. So, the updated nvmem definition could stay in the DTSI files as well. 2. For all other cases, splitting up the partition table would have introduced additional complexity. Thus, the nodes to be converted to nvmem have been moved to the DTS files where the partitioning was defined. 3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file was completely dissolved, as it was quite small and the name was not really nice either. 4. The D-Link DIR-853 A3 was converted to nvmem as well, though it is just a plain DTS file not taken care of in the first wave. In addition, some minor rearrangements have been made for tidyness. Not covered (yet) by this patch are: * Various unielec devices * The D-Link DIR-8xx family Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ipq40xx: fix Edgecore ECW5211 bootStijn Tintel2021-08-181-0/+1
| | | | | | | The bootloader will look for a configuration section named ap.dk01.1-c2 in the FIT image. If this doesn't exist, the device won't boot. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* ramips: add WPS button for newifi d1David Yang2021-08-171-1/+7
| | | | | | This device has a WPS button under WiFi antenna cover, add it to dts. Signed-off-by: David Yang <mmyangfl@gmail.com>
* ramips: mt7628: move mtd-eeprom out of root DTSIAdrian Schmutzler2021-08-1744-9/+90
| | | | | | | | | | | | | | | | | | | | | | | | The mt76x8 subtarget is the only one in ramips that stores the mediatek,mtd-eeprom property directly in the "root" mt7628an.dtsi. This is not optimal for a few different reasons: * If you don't really know it or are used to other (sub)targets, the property will be set somewhat magically. * The property is set based on &factory partition before (if at all) this partition is defined. * There are several devices that have different offset or even different partitions to read from, which will then be overwritten in the DTS files. Thus, definitions are scattered between root DTSI and individual files. Based on these circumstances, the "root" definition is removed and the property is added to the device-based DTS(I) files where needed and applicable. This should be easier to grasp for unexperienced developers and will move the property closer to the partition definitions. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* kernel: bump 5.10 to 5.10.59Rui Salvaterra2021-08-161-1/+1
| | | | | | No deleted or manually refreshed patches. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* base-files: rename 'sdcard' to 'legacy-sdcard'Daniel Golle2021-08-164-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While an image layout based on MBR and 'bootfs' partition may be easy to understand for users who are very used to the IBM PC and always have the option to access the SD card outside of the device (and hence don't really depend on other recovery methods or dual-boot), in my opinion it's a dead end for many desirable features on embedded systems, especially when managed remotely (and hence without an easy option to access the SD card using another device in case things go wrong, for example). Let me explain: * using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a single corruption of the bootfs can render the system into a state that it no longer boots at all. This makes dual-boot useless, or at least very tedious to setup with then 2 independent boot partitions to avoid the single point of failure on a "hot" block (the FAT index of the boot partition, written every time a file is changed in bootfs). And well: most targets even store the bootloader environment in a file in that very same FAT filesystem, hence it cannot be used to script a reliable dual-boot method (as loading the environment itself will already fail if the filesystem is corrupted). * loading the kernel uImage from bootfs and using rootfs inside an additional partition means the bootloader can only validate the kernel -- if rootfs is broken or corrupted, this can lead to a reboot loop, which is often a quite costly thing to happen in terms of hardware lifetime. * imitating MBR-boot behavior with a FAT-formatted bootfs partition (like IBM PC in the 80s and 90s) is just one of many choices on embedded targets. There are much better options with modern U-Boot (which is what we use and build from source for all targets booting off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623. Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix functions with 'legacy_sdcard_' instead of 'sdcard_'. Tested-by: Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* kernel: bump 5.4 to 5.4.140John Audia2021-08-148-89/+7
| | | | | | | | | | | | | | | | Removed upstreamed bcm27xx/patches-5.4: 950-0977-USB-gadget-f_hid-avoid-crashes-and-log-spam.patch 950-0980-SQUASH-USB-gadget-f_hid-remove-more-spam.patch All other patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Run-tested: ipq806x/R7800 No dmesg regressions, everything functional Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.4 to 5.4.139John Audia2021-08-1420-38/+39
| | | | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Run-tested: ipq806x/R7800 No dmesg regressions, everything functional Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: bump 5.10 to 5.10.58Rui Salvaterra2021-08-144-5/+5
| | | | | | No deleted or manually refreshed patches. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* kernel: bump 5.10 to 5.10.57Rui Salvaterra2021-08-146-18/+19
| | | | | | No deleted or manually refreshed patches. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* ipq40xx: ar40xx: reset port status registerDavid Bauer2021-08-141-2/+1
| | | | | | | This resolves incosnsitencies of the configured RX / TX flow control modes between different boards or bootloaders. Signed-off-by: David Bauer <mail@david-bauer.net>
* ipq40xx: ar40xx: use FIELD_GET macroDavid Bauer2021-08-141-7/+8
| | | | | | This improves code readability. Signed-off-by: David Bauer <mail@david-bauer.net>
* ipq40xx: increase EX6150v2 SPI frequencyDavid Bauer2021-08-141-1/+1
| | | | | | | | | The chip supports clock speeds up to 50 MHz, however it won't even read the chip-id correctly at this frequency. 45 MHz however works reliable. Signed-off-by: David Bauer <mail@david-bauer.net>
* bcm4908: add missing config symbolDavid Bauer2021-08-131-0/+1
| | | | Signed-off-by: David Bauer <mail@david-bauer.net>
* mediatek: add missing config symbolsDavid Bauer2021-08-132-0/+18
| | | | Signed-off-by: David Bauer <mail@david-bauer.net>
* tegra: add missing Kconfig symbolDavid Bauer2021-08-132-0/+2
| | | | Signed-off-by: David Bauer <mail@david-bauer.net>
* rockchip: add missing Kconfig symbolsDavid Bauer2021-08-131-0/+4
| | | | Signed-off-by: David Bauer <mail@david-bauer.net>
* generic: add missing config symbolDavid Bauer2021-08-111-0/+1
| | | | Signed-off-by: David Bauer <mail@david-bauer.net>
* mediatek: add missing config symbolDavid Bauer2021-08-113-0/+3
| | | | Signed-off-by: David Bauer <mail@david-bauer.net>
* treewide: add various missing config symbolsDavid Bauer2021-08-1019-3/+16
| | | | | | Fixes commit 91a52f22a13d ("treewide: backport support for nvmem on non platform devices") Signed-off-by: David Bauer <mail@david-bauer.net>
* generic: Kconfig: exit on unset symbolDavid Bauer2021-08-102-0/+22
| | | | | | | | | | | | | When a target configuration has unser Kconfig symbols, the build will fail when OpenWrt is compiled with V=s and stdin is connected to a tty. In case OpenWrt is compiled without either of these preconditions, the build will uscceed with the symbols in question being unset. Modify the kernel configuration in a way it fails on unset symbols regardless of the aformentioned preconditions. Signed-off-by: David Bauer <mail@david-bauer.net>
* generic: fix kernel panic on existing mac-address nodeDavid Bauer2021-08-102-16/+8
| | | | | | | | | | | | | Calling free for the OF property can result in a kernel panic, as the buffer in question might be referenced elsewhere. Also, it is not removed from the tree. Always allocate a new property and updating the tree with it fixes both issues. Fixes commit 91a52f22a13d ("treewide: backport support for nvmem on non platform devices") Signed-off-by: David Bauer <mail@david-bauer.net>
* omap: Remove EXT2 and EXT3 driver configHauke Mehrtens2021-08-091-4/+0
| | | | | | | | The EXT4 driver also takes care of EXT2 and EXT3 file systems. Activating the EXT2 driver kernel config options unlocked some other ext2 driver related options which OpenWrt did not take care of. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* layerscape: Fix multiple bugs in of_get_mac_address() changesHauke Mehrtens2021-08-0910-30/+24
| | | | | | | | | | | The change which backported the of_get_mac_address() change broke some patches in the layerscape target so the patches did not apply any more. This commit makes them apply again and also fixes some other problems related to this change. Fixes commit 91a52f22a13d ("treewide: backport support for nvmem on non platform devices") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: Apply change to of_get_mac_address() to ks8851 tooHauke Mehrtens2021-08-091-0/+38
| | | | | | | | | The code from ks8851.c was moved to ks8851_common.c, so it was not backported. This broke the compile of the omap target which uses this driver. Fixes commit 91a52f22a13d ("treewide: backport support for nvmem on non platform devices") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHzJosef Schlehofer2021-08-081-0/+39
| | | | | | | | | | | This patch is backported from linux-arm-kernel [1] to improve situation, when it was reported that 1.2 GHz variant is unstable with DFS. It waits to be accepted upstream, however, it waits for Marvell people to respond. [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/ Fixes: 7b868fe04a89 ("Revert "mvebu: 5.4 fix DVFS caused random boot crashes"") Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
* Revert "mvebu: 5.10 fix DVFS caused random boot crashes"Josef Schlehofer2021-08-081-107/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Based on the discussion on the mailing list [1], the patch which was reverted, it reverts only one patch without the subsequent ones. This leads to the SoC scaling issue not using a CPU parent clock, but it uses DDR clock. This is done for all variants, and it's wrong because commits (hacks) that were using the DDR clock are no longer in the mainline kernel. If someone has stability issues on 1.2 GHz, it should not affect all routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to improve the situation in the kernel and not making the situation worse. There are two solutions in cases of instability: a) disable cpufreq b) underclock it up to 1 GHz This reverts commit 080a0b74e39d159eecf69c468debec42f28bf4d8. [1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html Fixes: d37947681772 ("mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHz") CC: Pali Rohár <pali@kernel.org> Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
* layerscape: armv8_64b: do not disable CONFIG_IP_ADVANCED_ROUTERMartin Schiller2021-08-081-1/+0
| | | | | | | | This option is needed e.g. to use strongswan for IPSec. BTW: This was the only target where this option was disabled. Signed-off-by: Martin Schiller <ms@dev.tdt.de>
* gemini: Add hdparm settingLinus Walleij2021-08-081-0/+14
| | | | | | | | This uses "hdparm" (if present) to get the harddisk into low power mode on NAS set-ups. Cc: Adrian Schmutzler <mail@adrianschmutzler.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHzJosef Schlehofer2021-08-081-0/+39
| | | | | | | | | | This patch is backported from linux-arm-kernel [1] to improve situation, when it was reported that 1.2 GHz variant is unstable with DFS. It waits to be accepted upstream, however, it waits for Marvell people to respond. [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/ Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
* Revert "mvebu: 5.4 fix DVFS caused random boot crashes"Josef Schlehofer2021-08-081-107/+0
| | | | | | | | | | | | | | | | | | | | | | | | Based on the discussion on the mailing list [1], the patch which was reverted, it reverts only one patch without the subsequent ones. This leads to the SoC scaling issue not using a CPU parent clock, but it uses DDR clock. This is done for all variants, and it's wrong because commits (hacks) that were using the DDR clock are no longer in the mainline kernel. If someone has stability issues on 1.2 GHz, it should not affect all routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to improve the situation in the kernel and not making the situation worse. There are two solutions in cases of instability: a) disable cpufreq b) underclock it up to 1 GHz This reverts commit 080a0b74e39d159eecf69c468debec42f28bf4d8. [1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html CC: Pali Rohár <pali@kernel.org> Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
* mvebu: Turris Omnia: use SFP module, if presentKlaus Kudielka2021-08-081-1/+16
| | | | | | | | | | | | Follow the recommendations stated in the Turris Omnia DTS for eth2: "In case SFP module is present, U-Boot has to enable the sfp node above, remove phy-handle property, and add managed = "in-band-status" property." The boot script is written in a way, that it works for all U-Boot versions deployed by the vendor so far (2015.10-rc2, 2019.07). Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
* mvebu: backport Turris Omnia DTS changes to 5.4Klaus Kudielka2021-08-086-3/+249
| | | | | | | Kernel 5.4 receives a reduced set, just to make the SFP cage work. While we are at it, move the patches accepted upstream to the 0xx series. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
* mvebu: backport Turris Omnia DTS changes to 5.10Klaus Kudielka2021-08-086-4/+410
| | | | | | | Kernel 5.10 receives the complete set of improvements from 5.11/5.12. While we are at it, move the patches accepted upstream to the 0xx series. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
* ath79: fix the AR7{1,2}00 USB PHY patchesRui Salvaterra2021-08-082-4/+4
| | | | | | | PHY_SIMPLE is a bogus kconfig symbol, what we really need to select is GENERIC_PHY. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* kernel/generic: add CONFIG_KCSAN to the 5.10 kconfigRui Salvaterra2021-08-081-0/+1
| | | | | | | Add the missing CONFIG_KCSAN (disabled). Found while making kernel_oldconfig on an x86-64 subtarget. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 15:53:00 +0000