aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* kernel: bump 5.10 to 5.10.134John Audia2022-07-3011-14/+14
| | | | | | | All patches automatically rebased. Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 7be62b1187bb7e21bcdaadfc3d47713a91f05898)
* x86: update defconfig for 5.10.133John Audia2022-07-301-1/+7
| | | | | | | | | Add some new/missing symbols relating to speculative execution mitigations[1]. 1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/arch/x86/Kconfig?id=v5.10.133&id2=v5.10.132 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 56760c0b1316a0e379ff141b895c2929f0dace8d)
* kernel: bump 5.10 to 5.10.133John Audia2022-07-304-4/+4
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 913f160ac6c4dcf69ec0eb805c8a1cee809ace45)
* kernel: bump 5.10 to 5.10.132John Audia2022-07-3010-79/+18
| | | | | | | | | | All patches automatically rebased. The following patch was replaced by a similar version upstream: bcm27xx/patches-5.10/950-0036-tty-amba-pl011-Add-un-throttle-support.patch Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 7d3c0928de191b203dd5b27ddf208698d08639e3)
* octeon: add SUPPORTED_DEVICES to er/erlitePaul Spooren2022-07-291-0/+2
| | | | | | | | | | | | | | | | | Using the BOARD_NAME variable results for both er and erlite devices to identify themselfs as `er` and `erlite` (via `ubus call system board`). This is problematic when devices search for firmware upgrades since the OpenWrt profile is actually called `ubnt_edgerouter` and `ubnt_edgerouter-lite`. By adding the `SUPPORTED_DEVICE` a mapping is created to point devices called `er` or `erlite` to the corresponding profile. FIXES: https://github.com/openwrt/asu/issues/348 Signed-off-by: Paul Spooren <mail@aparcar.org> (cherry picked from commit 2a07270180ed0e295d854d6e9e59c78c40549efc)
* uboot-bcm4908: include SoC in output filesRafał Miłecki2022-07-282-4/+4
| | | | | | | | | This fixes problem of overwriting BCM4908 U-Boot and DTB files by BCM4912 ones. That bug didn't allow booting BCM4908 devices. Fixes: f4c2dab544ec2 ("uboot-bcm4908: add BCM4912 build") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit a8e1e30543239e85ff5dc220368164b66cf73fba)
* bcm4908: build bootfs image per-SoCRafał Miłecki2022-07-284-59/+92
| | | | | | | | | | | | | | | | | In theory we could have just 1 bootfs image for all devices as each device has its own entry in the "configurations" node. It doesn't work well with default configuration though. If something goes wrong U-Boot SPL can be interrupted (by pressing A) to enter its minimalistic menu. It allows ignoring boardid. In such case bootfs default configuration is used. For above reason each SoC family (BCM4908, BCM4912) should have its own bootfs built. It allows each of them to have working default configuration. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 6ae2f7ff4737ec8dbec026fc6c02f7d1850b521c)
* lantiq: fix network port GPIO settings for Fritzbox 3390Daniel Kestrel2022-07-231-2/+2
| | | | | | | | There are forum reports that 2 LAN ports are not working, the GPIO settings are adjusted to fix the problem. Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de> (cherry picked from commit 0f301b0b1d7ca4b5fe290a72f0434525405f5a26)
* ipq806x: Archer VR2600: fix switch ports numberingChristian Lamparter2022-07-231-3/+3
| | | | | | | | | The order of LAN ports shown in Luci is reversed compared to what is written on the case of the device. Fix the order so that they match. Fixes: #10275 Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (cherry picked from commit 69ea671320c936e72f554348475eeebcab383b42)
* realtek: correct egress frame port verificationSander Vanheule2022-07-212-39/+36
| | | | | | | | | | | | | | | | | | | | | Destination switch ports for outgoing frame can range from 0 to CPU_PORT-1. Refactor the code to only generate egress frame CPU headers when a valid destination port number is available, and make the code a bit more consistent between different switch generations. Change the dest_port argument's type to 'unsigned int', since only positive values are valid. This fixes the issue where egress frames on switch port 0 did not receive a VLAN tag, because they are sent out without a CPU header. Also fixes a potential issue with invalid (negative) egress port numbers on RTL93xx switches. Reported-by: Arınç ÜNAL <arinc.unal@xeront.com> Suggested-by: Birger Koblitz <mail@birger-koblitz.de> Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit 1773264a0c6da099af7f36046f95f0126d6de1eb)
* realtek: correct egress frame priority assignmentSander Vanheule2022-07-211-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Priority values passed to the egress (TX) frame header initialiser are invalid when smaller than 0, and should not be assigned to the frame. Queue assignment is then left to the switch core logic. Current code for RTL83xx forces the passed priority value to be positive, by always masking it to the lower bits, resulting in the priority always being set and enabled. RTL93xx code doesn't even check the value and unconditionally assigns the (32 bit) value to the (5 bit) QID field without masking. Fix priority assignment by only setting the AS_QID/AS_PRI flag when a valid value is passed, and properly mask the value to not overflow the QID/PRI field. For RTL839x, also assign the priority to the right part of the frame header. Counting from the leftmost bit, AS_PRI and PRI are in bits 36 and 37-39. The means they should be assigned to the third 16 bit value, containing bits 32-47. Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit 0b35a08a057848d909156604c4391a5d9f1d97e5)
* realtek: fix egress L2 learning on rtl839xSander Vanheule2022-07-211-1/+1
| | | | | | | | | | | | | The flag to enable L2 address learning on egress frames is in CPU header bit 40, with bit 0 being the leftmost bit of the header. This corresponds to BIT(7) in the third 16-bit value of the header. Correctly set L2LEARNING by fixing the off-by-one error. Fixes: 9eab76c84e31 ("realtek: Improve TX CPU-Tag usage") Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit d6165ea75baea4f9039f3a378d55219c74b932a7)
* realtek: fix egress port mask on rtl839xSander Vanheule2022-07-211-1/+1
| | | | | | | | | | | | | The flag to enable the outgoing port mask is in CPU header bit 43, with bit 0 being the leftmost bit of the header. This corresponds to BIT(4) in the third 16-bit value of the header. Correctly set AS_DPM by fixing the off-by-one error. Fixes: 9eab76c84e31 ("realtek: Improve TX CPU-Tag usage") Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit d9516cacb087fed7716b34b1e02ce956bb6c27f1)
* ramips: add support for Netgear WAX202Wenli Looi2022-07-216-0/+318
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Netgear WAX202 is an 802.11ax (Wi-Fi 6) router. Specifications: * SoC: MT7621A * RAM: 512 MiB NT5CC256M16ER-EK * Flash: NAND 128 MiB F59L1G81MB-25T * Wi-Fi: * MT7915D: 2.4/5 GHz (DBDC) * Ethernet: 4x 1GbE * Switch: SoC built-in * USB: None * UART: 115200 baud (labeled on board) Load addresses (same as ipTIME AX2004M): * stock * 0x80010000: FIT image * 0x81001000: kernel image -> entry * OpenWrt * 0x80010000: FIT image * 0x82000000: uncompressed kernel+relocate image * 0x80001000: relocated kernel image -> entry Installation: * Flash the factory image through the stock web interface, or TFTP to the bootloader. NMRP can be used to TFTP without opening the case. * Note that the bootloader accepts both encrypted and unencrypted images, while the stock web interface only accepts encrypted ones. Revert to stock firmware: * Flash the stock firmware to the bootloader using TFTP/NMRP. References in WAX202 GPL source: https://www.downloads.netgear.com/files/GPL/WAX202_V1.0.5.1_Source.rar * openwrt/target/linux/ramips/dts/mt7621-ax-nand-wax202.dts DTS file for this device. Signed-off-by: Wenli Looi <wlooi@ucalgary.ca> (cherry picked from commit 0f068e7c4a83bcbf20c4e52a5f8a3f1fe2af2246)
* kernel: Refresh kernel patchesHauke Mehrtens2022-07-194-11/+11
| | | | | | No manual changes needed. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: bump 5.10 to 5.10.130John Audia2022-07-193-6/+6
| | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Signed-off-by: John Audia <therealgraysky@proton.me>
* kernel: bump 5.10 to 5.10.129John Audia2022-07-198-20/+20
| | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Signed-off-by: John Audia <therealgraysky@proton.me>
* mt7622: remove 300 MHz from dtsJohn Audia2022-07-191-0/+25
| | | | | | | | | | | | | | | | | Due to the bug described here[1], remove the 300 MHz clock to avoid a low voltage condition that can cause a hang when rebooting the RT3200/E8450. This solution is probably better than the script-based work-around[2]. 1. https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302/1490 2. https://github.com/openwrt/openwrt/pull/5025 Signed-off-by: John Audia <therealgraysky@proton.me> Tested-by: Rui Salvaterra <rsalvaterra@gmail.com> Tested-by: John Audia <therealgraysky@proton.me> (cherry picked from commit d0d6b8e1833c587d0c50cac4f6324aa93b0bc8fc) [ fix the conflict by apply the patch to kernel 5.10 ] Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
* bcm4908: use upstream-accepted watchdog patchesRafał Miłecki2022-07-182-1/+11
| | | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 864fdf2bf3f4b5c71e57a27c514672b966580148)
* bcm4908: backport latest DT patchesRafał Miłecki2022-07-187-1/+363
| | | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 001856fa51eaa704a254955138f76907eb02c2b4)
* kernel: update leds-bcm63138 driverRafał Miłecki2022-07-183-0/+85
| | | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit bb2a2b1dbe9c03d2abbb6989b6c4041e765543b0)
* kernel: backport LEDs driver for BCMBCA devicesRafał Miłecki2022-07-185-0/+499
| | | | | | | This includes BCM63xx and BCM4908 families. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit d9ab1e56d8d16182bd292f393c012d7e6873ed89)
* ath79: bsap18x0: pad rootfs imageTomasz Maciej Nowak2022-07-151-1/+1
| | | | | | | | | | | This image is supposed to be written with help of bootloader to the flash, but as it stands, it's not aligned to block size and RedBoot will happily create non-aligned partition size in FIS directory. This could lead to kernel to mark the partition as read-only, therefore pad the image to block erase size boundary. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> (cherry picked from commit 9decd2a8436d2bb6b5f436268c92a6e6728486ce)
* ath79: ja76pf2: use nvmem cells to specify MAC addressesTomasz Maciej Nowak2022-07-152-4/+15
| | | | | | | | | | | | | The bootloader on this board hid the partition containig MAC addresses and prevented adding this space to FIS directory, therefore those had to be stored in RedBoot configuration as aliases to be able to assigne them to proper interfaces. Now that fixed partition size are used instead of redboot-fis parser, the partition containig MAC addresses could be specified, and with marking it as nvmem cell, we can assign them without userspace involvement. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> (cherry picked from commit b52719b71a3337e5ae840c7a50fe41ebdc070f4e)
* ath79: move image check for devices with RedBootTomasz Maciej Nowak2022-07-152-31/+46
| | | | | | | | | | | Don't comence the switch to RAMFS when the image format is wrong. This led to rebooting the device, which could lead to false impression that upgrade succeded. Being here, factor out the code responsible for upgrading RedBoot devices to separate file. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> (cherry picked from commit 5897c52e78e3cd3846db083d48dd9d6b47ff3a08)
* ath79: switch some RedBoot based devices to OKLI loaderTomasz Maciej Nowak2022-07-157-37/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the kernel has switched version to 5.10, JA76PF2 and RouterStations lost the capability to sysupgrade the OpenWrt version. The cause is the lack of porting the patches responsible for partial flash erase block writing and these boards FIS directory and RedBoot config partitions share the same erase block. Because of that the FIS directory can't be updated to accommodate kernel/rootfs partition size changes. This could be remedied by bootloader update, but it is very intrusive and could potentially lead to non-trivial recovery procedure, if something went wrong. The less difficult option is to use OpenWrt kernel loader, which will let us use static partition sizes and employ mtd splitter to dynamically adjust kernel and rootfs partition sizes. On sysupgrade from ath79 19.07 or 21.02 image, which still let to modify FIS directory, the loader will be written to kernel partition, while the kernel+rootfs to rootfs partition. The caveats are: * image format changes, no possible upgrade from ar71xx target images * downgrade to any older OpenWrt version will require TFTP recovery or usage of bootloader command line interface To downgrade to 19.07 or 21.02, or to upgrade if one is already on OpenWrt with kernel 5.10, for RouterStations use TFTP recovery procedure. For JA76PF2 use instructions from this commit message: commit 0cc87b3bacee ("ath79: image: disable sysupgrade images for routerstations and ja76pf2"), replacing kernel image with loader (loader.bin suffix) and rootfs image with firmware (firmware.bin suffix). Fixes: b10d6044599d ("kernel: add linux 5.10 support") Fixes: 15aa53d7ee65 ("ath79: switch to Kernel 5.10") Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> (mkubntimage was moved to generic-ubnt.mk) Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (cherry picked from commit 5c142aad7bc018fe000789740a486c49973035b8)
* rockchip: reliably distribute net interruptsRonny Kotzschmar2022-07-151-2/+9
| | | | | | | | | | On the NanoPI R4S it takes an average of 3..5 seconds for the network devices to appear in '/proc/interrupts'. Wait up to 10 seconds to ensure that the distribution of the interrupts really happens. Signed-off-by: Ronny Kotzschmar <ro.ok@me.com> (cherry picked from commit 9b00e9795660f53caf1f4f5fd932bbbebd2eeeb1)
* realtek: build sane factory images for DGS-1210 modelsMarkus Stockhausen2022-07-082-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | During upload of firmware images the WebUI and CLI patch process extracts a version information from the uploaded file and stores it onto the jffs2 partition. To be precise it is written into the flash.txt or flash2.txt files depending on the selected target image. This data is not used anywhere else. The current OpenWrt factory image misses this label. Therefore version information shows only garbage. Fix this. Before: DGS-1210-20> show firmware information IMAGE ONE: Version : xfo/QE~WQD"A\Scxq... Size : 5505185 Bytes After: DGS-1210-20> show firmware information IMAGE ONE: Version : OpenWrt Size : 5505200 Bytes Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> (cherry picked from commit fae3ac3560459320a88be86b31c572c4bca42645)
* realtek: build factory images for all DGS-1210 modelsMarkus Stockhausen2022-07-081-7/+7
| | | | | | | | | | Currently we build factory images only for DGS-1210-28 model. Relax that constraint and take care about all models. Tested on DGS-1210-20 and should work on other models too because of common flash layout. Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> (cherry picked from commit 2b49ec3a28ad09446f48f1f830a42bdfe3bce9be)
* realtek: rename u-boot-env2 to board-nameLuiz Angelo Daros de Luca2022-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | Some realtek boards have two u-boot-env partitions. However, in the DGS-1210 series, the mtdblock2 partition is not a valid u-boot env and simply contains the board/device name, followed by nulls. 00000000 44 47 53 2d 31 32 31 30 2d 32 38 2d 46 31 00 00 |DGS-1210-28-F1..| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00040000 00000000 44 47 53 2d 31 32 31 30 2d 35 32 2d 46 31 00 00 |DGS-1210-52-F1..| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00040000 The misleading u-boot-env2 name also confuses uboot-envtools. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> (cherry picked from commit 8b798dbb39856463878efb07ddef87ce2e522ceb)
* realtek: build DGS-1210 images with CAMEO tagMarkus Stockhausen2022-07-082-0/+5
| | | | | | | | | From now on we will insert CAMEO tags into sysupgrade images for DGS-1210 devices. This will make the "OS:...FAILED" and "FS:...FAILED" messages go away. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> (cherry picked from commit e763c4c89fc5569d7264ff60837eb4aff69a0bfb)
* realtek: add DGS-1210-28 factory imageLuiz Angelo Daros de Luca2022-07-082-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DGS-1210 switches support dual image, with each image composed of a kernel and a rootfs partition. For image1, kernel and rootfs are in sequence. The current OpenWrt image (written using a serial console), uses those partitions together as the firmware partition, ignoring the partition division. The current OEM u-boot fails to validate image1 but it will only trigger firmware recovery if both image1 and image2 fail, and it does not switch the boot image in case one of them fails the check. The OEM factory image is composed of concatenated blocks of data, each one prefixed with a 0x40-byte cameo header. A normal OEM firmware will have two of these blocks (kernel, rootfs). The OEM firmware only checks the header before writing unconditionally the data (except the header) to the correspoding partition. The OpenWrt factory image mimics the OEM image by cutting the kernel+rootfs firmware at the exact size of the OEM kernel partition and packing it as "the kernel partition" and the rest of the kernel and the rootfs as "the rootfs partition". It will only work if written to image1 because image2 has a sysinfo partition between kernel2 and rootfs2, cutting the kernel code in the middle. Steps to install: 1) switch to image2 (containing an OEM image), using web or these CLI commands: - config firmware image_id 2 boot_up - reboot 2) flash the factory_image1.bin to image1. OEM web (v6.30.016) is crashing for any upload (ssh keys, firmware), even applying OEM firmwares. These CLI commands can upload a new firmware to the other image location (not used to boot): - download firmware_fromTFTP <tftpserver> factory_image1.bin - config firmware image_id 1 boot_up - reboot To debrick the device, you'll need serial access. If you want to recover to an OpenWrt, you can replay the serial installation instructions. For returning to the original firmware, press ESC during the boot to trigger the emergency firmware recovery procedure. After that, use D-Link Network Assistant v2.0.2.4 to flash a new firmware. The device documentation does describe that holding RESET for 12s trigger the firmware recovery. However, the latest shipped U-Boot "2011.12.(2.1.5.67086)-Candidate1" from "Aug 24 2021 - 17:33:09" cannot trigger that from a cold boot. In fact, any U-Boot procedure that relies on the RESET button, like reset settings, will only work if started from a running original firmware. That, in practice, cancels the benefit of having two images and a firmware recovery procedure (if you are not consider dual-booting OpenWrt). Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> (cherry picked from commit 1005dc0a64587e954364ff3a64bbb38b2ca371cd)
* bcm53xx: enable & setup packet steeringRafał Miłecki2022-07-082-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Packet steering can improve NAT masquarade performance on Northstar by 40-50%. It makes reaching 940-942 Mb/s possible on BCM4708 (and obviously BCM47094 too). Add scripts setting up the most optimal Northstar setup. Below are testing results for running iperf TCP traffic from LAN to WAN. They were used to pick up golden values. ┌──────────┬──────────┬────────────────────┬────────────────────┐ │ eth0 │ br-lan │ flow_offloading=0 │ flow_offloading=1 │ │ │ ├─────────┬──────────┼─────────┬──────────┤ │ rps_cpus │ rps_cpus │ BCM4708 │ BCM47094 │ BCM4708 │ BCM47094 │ ├──────────┼──────────┼─────────┼──────────┼─────────┼──────────┤ │ 0 │ 0 │ 387 │ 671 │ 707 │ 941 │ │ 0 │ 1 │ 343 │ 576 │ 705 │ 941 │ │ 0 │ 2 │ ✓ 574 │ ✓ 941 │ 704 │ 940 │ │ 1 │ 0 │ 320 │ 549 │ 561 │ 941 │ │ 1 │ 1 │ 327 │ 551 │ 553 │ 941 │ │ 1 │ 2 │ 523 │ ✓ 940 │ 559 │ 940 │ │ 2 │ 0 │ 383 │ 652 │ ✓ 940 │ 941 │ │ 2 │ 1 │ 448 │ 754 │ ✓ 942 │ 941 │ │ 2 │ 2 │ 404 │ 655 │ ✓ 941 │ 941 │ └──────────┴──────────┴─────────┴──────────┴─────────┴──────────┘ Above tests were performed with all eth0 interrupts handled by CPU0. Setting "echo 2 > /proc/irq/38/smp_affinity" was tested on BCM4708 but it didn't increased speeds (just required different steering): ┌──────────┬──────────┬───────────┐ │ eth0 │ br-lan │ flow_offl │ │ rx-0 │ rx-0 │ oading=0 │ │ rps_cpus │ rps_cpus │ BCM4708 │ ├──────────┼──────────┼───────────┤ │ 0 │ 0 │ 384 │ │ 0 │ 1 │ ✓ 574 │ │ 0 │ 2 │ 348 │ │ 1 │ 0 │ 383 │ │ 1 │ 1 │ 412 │ │ 1 │ 2 │ 448 │ │ 2 │ 0 │ 321 │ │ 2 │ 1 │ 520 │ │ 2 │ 2 │ 327 │ └──────────┴──────────┴───────────┘ Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit fcbd39689ebfef20c62fe3882d51f3af765e8028)
* bcm53xx: disable GRO by default at kernel levelRafał Miłecki2022-07-081-0/+36
| | | | | | | | | | | This improves NAT masquarade network performance. An alternative to kernel change would be runtime setup but that requires ethtool and identifying relevant network interface and all related switch ports interfaces. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 82d0dd8f8aa11249944fe39cd0d75a1524ec22ec)
* bcm53xx: revert bgmac back to the old limited max frame sizeRafał Miłecki2022-07-081-0/+33
| | | | | | | | | | | | Bumping max frame size has significantly affected network performance. It was done by upstream commit that first appeared in the 5.7 release. This change bumps NAT masquarade speed from 196 Mb/s to 383 Mb/s for the BCM4708 SoC. Ref: f55f1dbaad33 ("bcm53xx: switch to the kernel 5.10") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 230c9da963aad9e1a2f8f128c30067ccad2efef8)
* kernel: drop patch adding hardcoded kernel compilation flagsRafał Miłecki2022-07-081-25/+0
| | | | | | | | | | | | | | | | | | | | 1. KCFLAGS should be used for custom flags 2. Optimization flags are arch / SoC specific 3. -fno-reorder-blocks may *worsen* network performace on some SoCs 4. Usage of flags was *reversed* since 5.4 and noone reported that If we really need custom flags then CONFIG_KERNEL_CFLAGS should get default value adjusted properly (per target). Ref: 4e0c54bc5bc8 ("kernel: add support for kernel 5.4") Link: http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038853.html Link: https://patchwork.ozlabs.org/project/openwrt/patch/20190409093046.13401-1-zajec5@gmail.com/ Cc: Felix Fietkau <nbd@nbd.name> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Rui Salvaterra <rsalvaterra@gmail.com> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 22168ae68101b95d03741b0e9e8ad20b8a5ae5b7)
* kernel: use KCFLAGS for passing EXTRA_OPTIMIZATION flagsRafał Miłecki2022-07-081-9/+3
| | | | | | | | | | This uses kernel's generic variable and doesn't require patching it with a custom Makefile change. It's expected *not* to change any behaviour. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 1d42af720c6b6dcfcdd0b89bce386fca1607dcb3) Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk> (cherry picked from commit 24e27bec9a6df1511a504cf04cd9578a23e74657)
* kernel: Add missing mediatek configuration optionsHauke Mehrtens2022-07-062-2/+3
| | | | | | | | | | | | When building the mediatek/mt7629 target in OpenWrt 22.03 the kernel does not have a configuration option for CONFIG_CRYPTO_DEV_MEDIATEK. Add this option to the generic kernel configuration and also add two other configuration options which are removed when we refresh the mt7629 kernel configuration. Fixes: 2bea35cb55d7 ("mediatek: remove crypto-hw-mtk package") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit dcc0fe24ea216d32300c0f01c8879e586d89cc1e)
* mediatek: mt7622: fix white dome LED of UniFi 6 LRDaniel Golle2022-07-041-3/+1
| | | | | | | | | | | The recent differentiation between v1 and v2 of the UniFi 6 LR added support for the v2 version which has GPIO-controlled LEDs instead of using an additional microcontroller to drive an RGB led. The polarity of the white LED, however, was inverted and the default states didn't make a lot of sense after all. Fix that. Signed-off-by: Daniel Golle <daniel@makrotopia.org> (cherry picked from commit f58e562b07803192d029a6be8c8c372e1ed11c68)
* mvebu: cortexa72: fix ImageBuilder for IEI Puzzle devicesDaniel Golle2022-07-041-2/+0
| | | | | | | | | | The line trying to generate the standard sdcard.img.gz fails due to boot.scr not being generated. Remove the line in order to use the default sdcard.img.gz which is exactly the same but includes generating the boot.scr file. Signed-off-by: Daniel Golle <daniel@makrotopia.org> (cherry picked from commit 1d3b57dbeeae70ab3a8f71d3bdb6fd41a00e1d22)
* mediatek: add Ubiquiti UniFi 6 LR v2 targetsHenrik Riomar2022-07-044-0/+239
| | | | | | | | | | | | | | | | Add targets: * Ubiquiti UniFi 6 LR v2 * Ubiquiti UniFi 6 LR v2 (U-Boot mod) This target does not have a RGB led bar like v1 did Used target/linux/ramips/dts/mt7621_ubnt_unifi.dtsi as inspiration The white dome LED is default-on, blue will turn on when the system is in running state Signed-off-by: Henrik Riomar <henrik.riomar@gmail.com> (cherry picked from commit 31d86a1a119265393db02aa66e6bc6518ee7b905)
* mediatek: new target ubnt_unifi-6-lr-v1-ubootmodHenrik Riomar2022-07-042-5/+6
| | | | | | | | | based on current ubnt_unifi-6-lr-ubootmod Signed-off-by: Daniel Golle <daniel@makrotopia.org> [added SUPPORTED_DEVICES for compatibility with existing setups] Signed-off-by: Henrik Riomar <henrik.riomar@gmail.com> (cherry picked from commit 5c8d3893a78fd81454930de30d90efaef99f8734)
* mediatek: new target mt7622-ubnt-unifi-6-lr-v1Henrik Riomar2022-07-045-31/+35
| | | | | | | | | | | | | Based on current mt7622-ubnt-unifi-6-lr, this is a preparation for adding a v2 version of this target * v1 - with led-bar * v2 - two simple GPIO connected LEDs (in later commits) Signed-off-by: Daniel Golle <daniel@makrotopia.org> [added SUPPORTED_DEVICES for compatibility with existing setups] Signed-off-by: Henrik Riomar <henrik.riomar@gmail.com> (cherry picked from commit 15a02471bb854245f8f94398c1e1d9ce29c2c341)
* mediatek: build ubnt-ledbar as a moduleChuanhong Guo2022-07-044-4/+18
| | | | | | | | | The config for LEDS_UBNT_LEDBAR doesn't stay in mt7629 kconfig because of its I2C dependency. Build it as a module and let buildroot handle this config option instead. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> (cherry picked from commit d9ea9c06e98b597174e0e94e0a13934637c0c03e)
* mediatek: remove crypto-hw-mtk packageEneas U de Queiroz2022-07-041-23/+0
| | | | | | | | The MediaTek's Crypto Engine module is only available for mt7623, in which case it is built into the kernel. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit 3f2d0703b60357e3ff1865783335be9f51528eb8)
* mediatek: mt7622: fix banana pi r64 wps buttonNick Hainke2022-07-041-0/+40
| | | | | | | | | | | | | | | | Fix the wps button to prevent wrongly detected recovery procedures. In the official banana pi r64 git the wps button is set to GPIO_ACTIVE_LOW and not GPIO_ACTIVE_HIGH. Import patch to fix on boot unwanted recovery entering: Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level - failsafe button wps was pressed - - failsafe - Signed-off-by: Nick Hainke <vincent@systemli.org> (cherry-picked from commit 668619425526cb0d43f8536a2f6f15a6314e6553)
* mediatek/mt7629: Activate CONFIG_ARM_ARCH_TIMER_EVTSTREAMHauke Mehrtens2022-07-031-0/+2
| | | | | | | | | | The kernel configuration option CONFIG_MACH_MT7629 selects CONFIG_HAVE_ARM_ARCH_TIMER now. Handle this change in the config-5.10. This fixes some build problems. Fixes: 81530d69ef58 ("kernel: bump 5.10 to 5.10.121") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: Refresh patches for all targetsHauke Mehrtens2022-07-0336-155/+79
| | | | | | | | | | | | | | | | This refreshes the patches on top of kernel 5.4.127. Deleted (upstreamed): bcm27xx/patches-5.10/950-0005-Revert-mailbox-avoid-timer-start-from-callback.patch [0] bcm27xx/patches-5.10/950-0678-bcm2711_thermal-Don-t-clamp-temperature-at-zero.patch [1] Needed manual modifications: bcm27xx/patches-5.10/950-0410-drm-atomic-Pass-the-full-state-to-CRTC-atomic-begin-.patch [0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.127&id=bb2220e0672b7433a9a42618599cd261b2629240 [1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.127&id=83603802954068ccd1b8a3f2ccbbaf5e0862acb0 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ramips: improve YunCore AX820 LEDsThibaut VARÈNE2022-07-011-6/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least two AX820 hardware variants are known to exist, but they cannot be distinguished (same hardware revision, no specific markings). They appear to have the same LED hardware, but wired differently: - One has a red system LED at GPIO 15, a green wlan2g LED at GPIO 14 and a blue wlan5g LED at GPIO 16; - The other only offers a green system LED at GPIO 15, with GPIO 14 and 16 being apparently not connected Finally, a Yuncore datasheet says the canonical wiring should be: - Blue wlan2g GPIO 14, green system GPIO 15, red wlan5g GPIO 16 All GPIOs are tied to a single RGB LED which is exposed via lightpipe on the device front casing. Considering the above, this patch exposes all three LEDs, preserves the common system LED (GPIO 15) as the openwrt status LED, and removes the color information from the LEDs names since it is not consistent across hardware. The LED naming is made consistent with other YunCore devices. A note is added in DTS to ensure this information is always available and prevent unwanted changes in the future. Fixes: #10131 "YunCore AX820: GPIO LED not correct" Reviewed-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
* kernel: bump 5.10 to 5.10.127John Audia2022-07-018-18/+18
| | | | | | | All patches automatically rebased. Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 433dc5892a60003753655aac6e6a4b59fb13b2e4)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-24 17:50:50 +0000