staging/stintel, branch master

realtek: dsa: rtl839x: offload tc flower rules to the PIE

2026-10-14T14:22:11Z

RTL839x has a PIE driver and an L3 that uses it, but no tc flower offload: the cls_flower callbacks sit only in the RTL93xx DSA ops, and tc is only set up where the PIE rule id doubles as a LOG counter, which holds on RTL930x alone. Give the families a pie_cls_flower flag for the offload and set it for RTL930x and RTL839x, set tc up from the RTL83xx setup too, and give the RTL83xx ops the cls_flower callbacks. RTL839x rules land in the ingress blocks before L3's, 0 to 4, and take their counters from the allocator. RTL930x keeps its behaviour, RTL931x has neither flag as before, and RTL838x, which shares the RTL83xx ops, refuses every flower rule as the DSA core did without them. Tested on an HPE 1920-48G (RTL8393), lan48 and lan47 tagged in VLAN 7, with "realtek: dsa: tc: tell IPv4 from IPv6 by the address type" applied; skip_sw rules on lan48 ingress, 8 frames each: - drop on dst_ip, src_ip, dst_mac, udp dst_port 5001, IPv6 dst_ip and vlan_id 7: 0 of 8 delivered, hardware count 8 (12 for the VLAN rule, which takes every VLAN 7 frame entering lan48); udp 5002 frames, frames to another IPv6 address, and VLAN 7 frames under a vlan_id 3 rule pass - trap: 8 of 8 at the CPU, where they stay; redirect to lan46: 0 of 8 delivered; mirror to lan46: 8 of 8 delivered, count 8; ethertype 0x88b5 to a MAC learnt on lan48, redirected or mirrored to lan47: 8 of 8 behind lan47, 0 without the rule - rules on lan47 leave frames entering lan48 alone - refused by the driver: src_mac, IPv6 src_ip, police, and any egress rule - a tc drop on a prefix routed in hardware, on the switch's own address and on a bridged host inside a gateway /28: 0 of 8 routed, answered or delivered, count 8 The L3 round passes with the series, apart from its check of the old block layout (see the previous commit). Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Gennaro Cimmino Link: https://github.com/openwrt/openwrt/pull/25884 Signed-off-by: Markus Stockhausen

realtek: dsa: rtl839x: put L3 rules after the ingress ACLs

2026-10-14T14:22:11Z

L3 holds the first four PIE blocks of RTL839x. Where two blocks match a frame, the forwarding action of the lower one wins (measured below), so an L3 rule beats an ingress ACL rule placed after it, while in the kernel tc ingress runs before routing. Move L3 to the last four ingress blocks, 5 to 8, under the cutline at 9, and leave blocks 0 to 4 to the ingress ACL rules. L3 keeps its own row numbers: rtl839x_pie_l3_rule_write() and a new rtl839x_pie_l3_rule_read() add the offset, and the debugfs dump shows the PIE index. The cutline gets a name, RTL839X_PIE_CUTLINE, as L3's first rule now follows from it. Nothing but L3 uses the RTL839x PIE so far. Tested on an HPE 1920-48G (RTL8393) with the series and "realtek: dsa: tc: tell IPv4 from IPv6 by the address type": L3's rules show at PIE index 640 and up, and 19 of the 20 checks of the L3 round pass; the other one looks for L3's templates on blocks 0 to 3 and reads 2 and 3 on blocks 0 to 4 and 1 and 3 on block 5, as intended. With the flower offload that follows, a tc drop now wins over a route in hardware, the switch's own address and a bridged host inside a gateway /28: 0 of 8 frames get through in each case, where with L3 in blocks 0 to 3 all 8 did. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Gennaro Cimmino Link: https://github.com/openwrt/openwrt/pull/25884 Signed-off-by: Markus Stockhausen

realtek: dsa: rtl839x: clear LOG counters with CLRL/CLRH

2026-10-14T14:22:11Z

On RTL839x a write to the LOG table stores no data: its address picks the half of an entry to clear, ADDR[11:0] = {CLRH, CLRL, index[9:0]} (dal_cypress_acl_statPktCnt_clear() in the GPL SDK). The packet counter clear reads the entry, zeroes one half in the buffer and writes it back at its plain index, which clears nothing. Nothing calls it on RTL839x yet; once flower rules take their counters from the allocator, a counter handed out again would start from the count of its last user. Give otto_table the two clear views of the RTL8390 LOG table, at the offsets of CLRL and CLRH, and clear a counter by writing to its half there. Only the RTL839x counter clear uses them. Tested on an HPE 1920-48G (RTL8393) with the flower offload that follows: without this change the first hardware count of a rule was 76 for 8 dropped frames, its counter having been used before; with it, 8. Two rules sharing one LOG entry (counters 0 and 1): deleting either leaves the other counting on (16 after 8 and 8), and the counter handed out again starts from 0. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Gennaro Cimmino Link: https://github.com/openwrt/openwrt/pull/25884 Signed-off-by: Markus Stockhausen

realtek: dsa: tc: take a counter where the rule id is none

2026-10-14T14:22:11Z

A PIE flower rule counts its packets in the LOG table entry its rule id names, which holds on RTL930x, the only family offloading flower rules to the PIE so far: there the rule id doubles as the LOG counter id, and the counter allocator keeps that range for it. RTL839x has no such property, and its L3 rules take their counters from otto_stats_packet_cntr_alloc(). Where the rule id is not a counter id, take a counter from the allocator before placing the rule, point the rule's LOG index at it, and give it back on every way the flow ends: a setup that fails after taking it, a delete, and the teardown of the whole table. RTL930x keeps the counter its rule id implies. Nothing reaches the new path until a family without that property offloads flower rules. Tested with the rest of the series on an HPE 1920-48G (RTL8393): 50 add/delete cycles of one rule all took counter 0, and after rules refused by the PIE (src_mac, IPv6 src_ip) the next rule took counter 0 again. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Gennaro Cimmino Link: https://github.com/openwrt/openwrt/pull/25884 Signed-off-by: Markus Stockhausen

realtek: dsa: tc: tell IPv4 from IPv6 by the address type

2026-10-14T11:13:21Z

cls_flower keeps a rule's IPv4 and IPv6 addresses in one union of its flow key, and counts a key as used when any byte of its mask is set. A rule on IPv4 addresses therefore has FLOW_DISSECTOR_KEY_IPV4_ADDRS and FLOW_DISSECTOR_KEY_IPV6_ADDRS both in used_keys, and the check that refuses a rule combining the two refuses every IPv4 address rule before it reaches the PIE. On RTL930x: tc filter add dev lan2 ingress protocol ip flower skip_sw \ dst_ip 10.0.20.1 action drop rtl83xx-switch 1b000000.ethernet-switch: flower rule setup failed: -122 RTNETLINK answers: Not supported and without skip_sw the rule stays in software (not_in_hw). An IPv6 rule with a source address has both keys in use as well. The address type in the control key is what cls_flower sets to tell the two apart, but it is set for a /0 prefix too, whose key is not in use: pick the addresses by the type and the key together, and drop the check. On RTL930x, IPv4 address rules added without skip_sw so far ran in software only, on the frames that reach the CPU; they now go in hardware, so by code they apply to the frames the switch forwards as well (the test below only sent pings to the switch). Tested on a Hasivo S1100W-8XGT-SE (RTL9303), rules on lan2 ingress, 8 pings to the switch: on main the skip_sw IPv4 dst_ip and src_ip rules fail as above and the dst_ip rule without skip_sw stays not_in_hw; with this change, applied together with the RTL839x flower offload series, all three are in hardware, drop 8 of 8 and count 8. IPv6 dst_ip and ::/0 rules are offloaded before and after, an IPv6 src_ip rule is refused before and after. On an HPE 1920-48G (RTL8393) with the RTL839x flower offload series, IPv4 dst_ip and src_ip rules drop 8 of 8 bridged frames, and ::/0 drops the IPv6 test frames to both addresses (16 of 16). Fixes: 9d3500939a7b ("realtek: dsa: rtl83xx: validate tc flower match keys and actions") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Gennaro Cimmino Link: https://github.com/openwrt/openwrt/pull/25883 Signed-off-by: Markus Stockhausen

realtek: l3: log route changes at debug level

2026-10-14T08:57:40Z

Every route that is added prints three info lines and every route that is deleted prints two. The printing holds the work queue that programs the routes: with a serial console at 115200 baud, 1800 routes through one gateway take 77 seconds to reach the hardware on RTL9303 and 53 seconds to leave it. Print these lines at debug level, and with them the warning for the addresses the driver never offloads. The same routes are then programmed in 4 seconds and removed in 5 or less. Errors stay where they were. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Quinn O'Shea Link: https://github.com/openwrt/openwrt/pull/25885 Signed-off-by: Markus Stockhausen

realtek: l3: program only the new route when its gateway is resolved

2026-10-14T08:57:39Z

A route added through a gateway that is already resolved goes through otto_l3_nexthop_update(), which reprograms every route through that gateway. Adding routes in bulk is quadratic: on RTL9303, 1800 routes through one gateway take 1219 seconds to reach the hardware. The others are in hardware already, so program the new one alone. The same 1800 routes then take 77 seconds. Read the neighbour's address under its lock while at it, as the netevent handler does. The same resolve brings routes back when the policy rules let them forward again, when a local prefix around them comes or goes, and on RTL839x when the switch MAC of their device changes. These called it once per gateway, skipping the others through otto_l3_gw_seen(), and relied on otto_l3_nexthop_update() to reprogram every route through it. Each of these routes is now resolved on its own, and otto_l3_gw_seen() goes. Routes the change does not concern, such as those outside the local prefix, are no longer reprogrammed with them. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Quinn O'Shea Link: https://github.com/openwrt/openwrt/pull/25885 Signed-off-by: Markus Stockhausen

qualcommax: ipq50xx: fix IPQ5018 internal radio startup

2026-10-14T08:25:14Z

The qcom_q6v5_mpd driver applies the MSA lock before selecting the IPQ5018 internal-radio power-up sequence. The original IPQ5018 MPD implementation powers the internal AHB radio through dedicated SCM calls without applying the MSA lock. Firmware on the Wallys DR5018S rejects the lock for PASID 0x112 with -EINVAL, leaving pd-1 offline and the integrated 2.4 GHz radio unavailable. Add a per-SoC flag for the IPQ5018 MSA-lock exception and combine it with ASID 1 only when applying the lock and unlock. Keep the existing ASID-based selection of the internal Wi-Fi SCM calls unchanged, so IPQ5332 and IPQ9574 retain their current behavior. External QCN6122 protection domains continue to use the generic MSA sequence. Tested on Wallys DR5018S. The parent WCSS and pd-1 through pd-3 reach the running state, and all three ath11k radios register. Signed-off-by: Alan Gao <1226010136@qq.com>

qualcommax: ipq50xx: add support for Wallys DR5018S

2026-10-14T08:18:19Z

The Wallys DR5018S is an IPQ5018-based tri-band Wi-Fi 6E board. Product specification: https://www.wallystech.com/upload/DR5018S.pdf Hardware: - Qualcomm IPQ5018 SoC - 512 MB DDR3L RAM - 8 MB SPI NOR flash (Macronix MX25U6435F) - 128 MB SPI NAND flash (GigaDevice GD5F1GM7REYIG) - 1 x 1 GbE LAN port using the integrated GEPHY - 1 x 2.5 GbE WAN port using a QCA8081 PHY - 2x2 2.4 GHz Wi-Fi 6 using the integrated radio - 2x2 5 GHz and 2x2 6 GHz Wi-Fi 6E using QCN6122 radios - 1 x USB 2.0 pin-header interface - 1 x reset button - 4 x blue status LEDs - UART: J3 next to the USB header, 115200 8N1 - pin 1: 3.3 V (do not connect) - pin 2: TX - pin 3: RX - pin 4: GND - Power: 12-52 V DC jack, or 802.3at/bt and passive 48 V PoE (the manufacturer does not publish a DC current rating) The SPI NOR contains the boot chain, U-Boot environment and ART partitions. The SPI NAND contains the training area and two 62 MiB rootfs slots. Add the device tree, FIT/UBI image definitions, network defaults, calibration extraction, U-Boot environment access and NAND sysupgrade support. MAC addresses: - LAN: stored in ART at offset 0x0 and read through an NVMEM mac-base cell - WAN: stored in ART at offset 0x6 and read through an NVMEM mac-base cell - 2.4 GHz: stored in the ART calibration block at offset 0x100e - 5 GHz: stored in the ART calibration block at offset 0x2680e - 6 GHz: stored in the ART calibration block at offset 0x4c00e The three Wi-Fi calibration blocks are extracted from ART and retain their stored per-radio MAC addresses; they are not derived from the Ethernet MAC addresses. The sysupgrade handler removes OEM-only UBI volumes before creating the OpenWrt kernel, rootfs and rootfs_data volumes. Installation: 1. Connect to the J3 serial console and interrupt the vendor U-Boot. Copy the generated initramfs-uImage.itb to the TFTP root as initramfs.itb, then configure TFTP and boot it: setenv serverip 192.168.1.10 setenv ipaddr 192.168.1.1 tftpboot 0x44000000 initramfs.itb bootm 0x44000000 2. Transfer the generated squashfs-sysupgrade.bin to the device as /tmp/sysupgrade.bin and install it: sysupgrade -n /tmp/sysupgrade.bin Reverting to the vendor firmware has not been tested. Back up the complete SPI NOR and both SPI NAND rootfs slots before installing OpenWrt. Dependencies: - CMN PLL boot fix: https://github.com/openwrt/openwrt/pull/24653 - Internal radio fix: https://github.com/openwrt/openwrt/pull/24909 - Board data: https://github.com/openwrt/firmware_qca-wireless/pull/149 Tested on a Wallys DR5018S with the dependencies above applied: - initramfs boot from the vendor U-Boot - installation to SPI NAND and subsequent sysupgrade - repeated cold boots - 1 GbE LAN and 2.5 GbE WAN - 2.4 GHz, 5 GHz and 6 GHz AP interfaces - USB 2.0 host-controller registration - four blue status LED outputs Signed-off-by: Alan Gao <1226010136@qq.com> Link: https://github.com/openwrt/openwrt/pull/24910 Signed-off-by: Robert Marko

qualcommax: ipq50xx: add support for Linksys MR2000

2026-10-14T08:16:19Z

Add support for Linksys MR2000-family routers based on Qualcomm IPQ5018, including the MR20WH (LN3111) and MR20EC variants. Hardware: - Qualcomm IPQ5018 - 512 MiB RAM - GigaDevice GD5F2GQ5REYIH 256 MiB SPI-NAND - QCA8337 switch with four Gigabit LAN ports over SGMII - dedicated IPQ5018 internal Gigabit Ethernet PHY for WAN - IPQ5018 2.4 GHz 802.11ax - QCN6122 5 GHz 802.11ax - USB host port - RGB status LED - reset and WPS buttons - 12 V / 1.5 A power input The MR20WH uses the same stock firmware as the MR2000 family, so use MR2000 as the canonical OpenWrt board identity. The tested hardware was an MR20WH (LN3111). The board support was initially derived from the existing MX2000 support, but the MR2000 family differs from the MX2000 in Ethernet topology, GPIO assignments and NAND partitioning. UART is available on the four-pin header on the left PCB edge. With the Ethernet ports facing down, the pins from top to bottom are RX, TX, GND and +5V. The serial console uses 115200 8N1. The base MAC address is stored as hw_mac_addr in the devinfo partition. LAN and WAN use the base address. The 2.4 GHz and 5 GHz radios use base +1 and base +2 respectively. Use Qualcomm SMEM partition discovery instead of board-specific fixed partitions. Retain Linksys dual-bank upgrade handling, pending further validation of the NAND layout. The factory image can be installed directly from the stock Linksys firmware web interface. The factory image now inherits the MR2000 Linksys image type from the common device recipe. For recovery and development, initramfs can be loaded from stock U-Boot using TFTP: setenv ethact eth1 setenv ipaddr 192.168.1.1 setenv serverip 192.168.1.10 tftpboot 0x44000000 bootm 0x44000000 After OpenWrt is installed, use the normal sysupgrade image for subsequent upgrades. USB 2.0 hotplug, mass storage and the USB status LED were verified on hardware. USB 3.0 SuperSpeed was verified at 5000 Mbps using a RAM-patched device tree with the upstream dual-PHY configuration. The MR2000-specific IPQ5018 and QCN6122 board files were extracted from stock Linksys firmware and submitted to firmware_qca-wireless PR #169. Select the matching MR2000 calibration variants and ipq-wifi package. The firmware source revision must be updated after the board files are merged. Add the MR2000 uboot-envtools configuration and register the MR2000-specific ipq-wifi package. Signed-off-by: Joe Aear <360alaska@gmail.com> Link: https://github.com/openwrt/openwrt/pull/25673 Signed-off-by: Robert Marko