staging/ansuel/target, branch master

mediatek: 5.15: refresh patches

2022-07-01T18:24:44Z

Refresh patches: - 510-net-mediatek-add-flow-offload-for-mt7623.patch - 920-dts-mt7622-bpi-r64-fix-wps-button.patch Signed-off-by: Nick Hainke

generic: 5.15: refresh patches

2022-07-01T18:24:43Z

Refresh patches: - 402-mtd-blktrans-call-add-disks-after-mtd-device.patch - 420-mtd-set-rootfs-to-be-root-dev.patch - 495-mtd-core-add-get_mtd_device_by_node.patch Signed-off-by: Nick Hainke

mediatek: mt7622: fix banana pi r64 wps button

2022-07-01T18:24:43Z

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

ath79: use rtl8366s and rtl8366_smi as a module

2022-07-01T18:22:53Z

rtl8366s is used only by dlink_dir-825-b1 and the netgear_wndr family (wndr3700, wndr3700-v2, wndr3800ch, wndr3800.dts, wndrmac-v1, wndrmac-v2). Not tested in real hardware. With rtl8366rb, rtl8366s, rtl8367 as modules, rtl8366_smi can also be a loadable module. This change was tested with tl-wr2543-v1. Signed-off-by: Luiz Angelo Daros de Luca

ath79: use rtl8367 as a module

2022-07-01T18:22:52Z

rtl8367 is used only by tl-wr2543-v1. Tested both normal and failsafe modes. Signed-off-by: Luiz Angelo Daros de Luca

ath79: use rtl8366rb as a module

2022-07-01T18:22:52Z

It looks like rtl8366rb is used only by tplink_tl-wr1043nd-v1 and buffalo_wzr-hp-g300nh-rb. There is no need to have it built-in as it works as a loadable module. Tested both failsafe and normal boot on tl-wr1043nd-v1. buffalo_wzr-hp-g300nh-rb was not tested. Signed-off-by: Luiz Angelo Daros de Luca

ramips: improve YunCore AX820 LEDs

2022-07-01T18:13:46Z

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 Signed-off-by: Thibaut VARÈNE

qoriq: enable Book-E Watchdog Timer

2022-07-01T13:26:51Z

Enable PowerPC Book-E Watchdog Timer support. Having this enabled in-kernel will result in procd starting it during boot. This effectively solves the problem of the WDT in the Winbond W83793 chip potentially resetting the system during sysupgrade, which could result in an unbootable device. While the driver is modular, resulting in procd not starting the WDT during boot (because that happens before kmod load), the WDT handover during sysupgrade results in the WDT being started. This normally shouldn't be a problem, but the W83793 WDT does not like procd's defaults, nor the handover happening during sysupgrade. Signed-off-by: Stijn Tintel

bcm27xx: add support for Raspberry Pi Zero 2

2022-07-01T09:56:56Z

Due to licensing uncertainty, we do not include the firmwares for the wireless chips used in the Raspberry Pi Zero 2 W. To have working wireless, follow the instructions below. For people building their own images: mkdir -p files/lib/firmware/brcm wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436-sdio.bin wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436-sdio.txt wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436s-sdio.bin wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436s-sdio.txt Now build the OpenWrt image as usual, and it will include the firmware files in the correct location. For people using ext4 images: Write the ext4 image to the sdcard, then mount the 2nd partition and put the firmware files from the links above in /lib/firmware/brcm relative from the mount point where the partition is mounted. For people using squashfs images: Write the squashfs image to the sdcard, place it in the Raspberry Pi Zero 2 W, boot it and wait for the overlay filesystem to be created. Find the offset of the overlay filesystem in sysfs: # cat /sys/devices/virtual/block/loop0/loop/offset 25755648 Shut down the device, unplug the power and move the SD card to a Linux computer. Mount the 2nd partition of the sdcard as a loop device with the offset found earlier. sudo mount /dev/sdh2 -o loop,offset=25755648 /mnt/temp Put the firmware files from the links above in /upper/lib/firmware/brcm relative to the mount point where the loop device is mounted. Signed-off-by: Stijn Tintel Tested-by: Peter van Dijk

ath79: add support for ASUS RP-AC51

2022-06-29T22:23:42Z

Asus RP-AC51 Repeater Category: AC750 300+433 (OEM w. unstable driver) AC1200 300+866 (OpenWrt w. stable driver) Hardware specifications: Board: AP147 SoC: QCA9531 2.4G b/g/n WiFi: QCA9886 5G n/ac DRAM: 128MB DDR2 Flash: gd25q128 16MB SPI-NOR LAN/WAN: AR8229 1x100M Clocks: CPU:650MHz, DDR:600MHz, AHB:200MHz MAC addresses as verified by OEM firmware: use address source Lan/W2G *:C8 art 0x1002 (label) 5G *:CC art 0x5006 Installation: Asus windows recovery tool: install the Asus firmware restoration utility unplug the router, hold the reset button while powering it on release when the power LED flashes slowly specify a static IP on your computer: IP address: 192.168.1.75 Subnet mask 255.255.255.0 Start the Asus firmware restoration utility, specify the factory image and press upload Do not power off the device after OpenWrt has booted until the LED flashing. TFTP Recovery method: set computer to a static ip, 192.168.1.10 connect computer to the LAN 1 port of the router hold the reset button while powering on the router for a few seconds send firmware image using a tftp client; i.e from linux: $ tftp tftp> binary tftp> connect 192.168.1.1 tftp> put factory.bin tftp> quit Signed-off-by: Tamas Balogh