Started by timer with parameters: {BUILD_CFG_TARGET_DEV=WR8750N/WR9500N/WG600HP (AR9344)}BUILD_CFG_DISTCLEANtrueBUILD_CFG_DIFFCONFIGtrueBUILD_CFG_TARGET_DEVWR8750N/WR9500N/WG600HP (AR9344)488f3614686abca9e37249c9203822858a5cdbef8cef3614686abca9e37249c9203822858a5cdbef8cerefs/remotes/origin/mainf3614686abca9e37249c9203822858a5cdbef8cef3614686abca9e37249c9203822858a5cdbef8cerefs/remotes/origin/mainf3614686abca9e37249c9203822858a5cdbef8cef3614686abca9e37249c9203822858a5cdbef8cerefs/remotes/origin/mainhttps://github.com/openwrt/openwrthttps://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/488/artifacthttps://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/changeshttps://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/488/https://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/488/testReportconfig.buildinfoconfig.buildinfobin/targets/ath79/tiny/config.buildinfofeeds.buildinfofeeds.buildinfobin/targets/ath79/tiny/feeds.buildinfoopenwrt-ath79-tiny-nec_wg600hp-initramfs-factory.binopenwrt-ath79-tiny-nec_wg600hp-initramfs-factory.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wg600hp-initramfs-factory.binopenwrt-ath79-tiny-nec_wg600hp-initramfs-kernel.binopenwrt-ath79-tiny-nec_wg600hp-initramfs-kernel.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wg600hp-initramfs-kernel.binopenwrt-ath79-tiny-nec_wg600hp-squashfs-sysupgrade.binopenwrt-ath79-tiny-nec_wg600hp-squashfs-sysupgrade.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wg600hp-squashfs-sysupgrade.binopenwrt-ath79-tiny-nec_wg600hp-uboot.binopenwrt-ath79-tiny-nec_wg600hp-uboot.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wg600hp-uboot.binopenwrt-ath79-tiny-nec_wr8750n-initramfs-factory.binopenwrt-ath79-tiny-nec_wr8750n-initramfs-factory.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr8750n-initramfs-factory.binopenwrt-ath79-tiny-nec_wr8750n-initramfs-kernel.binopenwrt-ath79-tiny-nec_wr8750n-initramfs-kernel.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr8750n-initramfs-kernel.binopenwrt-ath79-tiny-nec_wr8750n-squashfs-sysupgrade.binopenwrt-ath79-tiny-nec_wr8750n-squashfs-sysupgrade.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr8750n-squashfs-sysupgrade.binopenwrt-ath79-tiny-nec_wr8750n-uboot.binopenwrt-ath79-tiny-nec_wr8750n-uboot.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr8750n-uboot.binopenwrt-ath79-tiny-nec_wr9500n-initramfs-factory.binopenwrt-ath79-tiny-nec_wr9500n-initramfs-factory.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr9500n-initramfs-factory.binopenwrt-ath79-tiny-nec_wr9500n-initramfs-kernel.binopenwrt-ath79-tiny-nec_wr9500n-initramfs-kernel.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr9500n-initramfs-kernel.binopenwrt-ath79-tiny-nec_wr9500n-squashfs-sysupgrade.binopenwrt-ath79-tiny-nec_wr9500n-squashfs-sysupgrade.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr9500n-squashfs-sysupgrade.binopenwrt-ath79-tiny-nec_wr9500n-uboot.binopenwrt-ath79-tiny-nec_wr9500n-uboot.binbin/targets/ath79/tiny/openwrt-ath79-tiny-nec_wr9500n-uboot.binopenwrt-ath79-tiny.manifestopenwrt-ath79-tiny.manifestbin/targets/ath79/tiny/openwrt-ath79-tiny.manifestprofiles.jsonprofiles.jsonbin/targets/ath79/tiny/profiles.jsonsha256sumssha256sumsbin/targets/ath79/tiny/sha256sumsversion.buildinfoversion.buildinfobin/targets/ath79/tiny/version.buildinfofalsediffconfig: true, device: WR8750N/WR9500N/WG600HP (AR9344)#48821962192233171OpenWrt (master) for NEC Aterm (NetBSD based) #488488falsefalse48853SUCCESS1788997200106https://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/488/home-slave02_taihasv- target/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.ctarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.hd7c8cb572ec87f70419cde2f04a970a1d098ad3c1788761476000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: eth: rtl960x: fixup setting of rx ring size and flow control values
The current way of setting 1st rx ring and its flow control threshold values
are not exactly correct and doesn't follow register layout. In reality, the
register layout is much worse but still need to followed. This however, is
not the case for rx rings 2-6 as they have more sane register layouts.
Fix this up even if it is not the prettiest thing.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25042
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-07 08:11:16 +0200d7c8cb572ec87f70419cde2f04a970a1d098ad3crealtek: eth: rtl960x: fixup setting of rx ring size and flow control valuesedittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.hedittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.c
- target/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.ctarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.h7ae1a716afe42ebf4690bd0229d476c29f5c6d431788761476000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: eth: rtl960x: remove 8-bit regmap
The last user of 8-bit regmap is GMAC_CMD register which can just as
well use 32-bit regmap whichout any issues. Change the register to
align with 4 byte and with that delete all of the 8-bit regmap stuff.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25042
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-07 08:11:16 +02007ae1a716afe42ebf4690bd0229d476c29f5c6d43realtek: eth: rtl960x: remove 8-bit regmapedittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.hedittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.c
- target/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.cd95ef3c999026fa58d60d960f6d660ddeaad180c1788761476000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: eth: rtl960x: remove static asserts of descriptors
These asserts seem to be unnecessary as in all normal build cases the u32
is 4 bytes making rtl960x_rx_desc to be size of 16 and rtl960x_tx_desc
size of 20.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25042
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-07 08:11:16 +0200d95ef3c999026fa58d60d960f6d660ddeaad180crealtek: eth: rtl960x: remove static asserts of descriptorsedittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.c
- target/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.ce1f69d04e09b099f783e51188bb6a40eb03003291788761476000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: eth: rtl960x: increase ring sizes and buf size
The GMAC on RTL9607C can handle ring sizes of up to 4096. Fix the comment
to now say 4096 is max instead of 256 and change the rx/tx ring sizes to 1024
and 2048 respectively to follow the vendor's defaults from their nic driver.
Also change the RX_BUF_SIZE to 1600 as the mentioned nic driver has the
SKB_BUF_SIZE set to 1600.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25042
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-07 08:11:16 +0200e1f69d04e09b099f783e51188bb6a40eb0300329realtek: eth: rtl960x: increase ring sizes and buf sizeedittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl960x_gmac.c
- target/linux/generic/backport-6.12/504-v7.3-ksmbd-fix-listener-task-lifetime-on-netdev-events.patchtarget/linux/generic/backport-6.18/500-v6.19-ksmbd-server-avoid-busy-polling-in-accept-loop.patchtarget/linux/generic/backport-6.18/504-v7.3-ksmbd-fix-listener-task-lifetime-on-netdev-events.patchtarget/linux/generic/backport-6.12/503-02-v7.3-ksmbd-keep-tcp-timers-alive-for-kernel-sockets.patchtarget/linux/generic/backport-6.12/503-01-v7.3-ksmbd-enable-tcp-keepalive-for-accepted-connections.patchtarget/linux/generic/backport-6.18/503-01-v7.3-ksmbd-enable-tcp-keepalive-for-accepted-connections.patchtarget/linux/generic/backport-6.12/501-v6.19-ksmbd-server-avoid-busy-polling-in-accept-loop.patchtarget/linux/generic/backport-6.18/503-02-v7.3-ksmbd-keep-tcp-timers-alive-for-kernel-sockets.patchdc4c2150806b4b7d8dd114051cd9b0ee9f7875a81788767705000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comkernel: ksmbd: avoid busy polling
Backport a patch to use blocking kernel_accept() and a fix for it,
avoiding busy polling.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24987
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 09:55:05 +0200dc4c2150806b4b7d8dd114051cd9b0ee9f7875a8kernel: ksmbd: avoid busy pollingaddtarget/linux/generic/backport-6.12/501-v6.19-ksmbd-server-avoid-busy-polling-in-accept-loop.patchedittarget/linux/generic/backport-6.12/503-01-v7.3-ksmbd-enable-tcp-keepalive-for-accepted-connections.patchedittarget/linux/generic/backport-6.18/503-02-v7.3-ksmbd-keep-tcp-timers-alive-for-kernel-sockets.patchaddtarget/linux/generic/backport-6.18/500-v6.19-ksmbd-server-avoid-busy-polling-in-accept-loop.patchedittarget/linux/generic/backport-6.18/503-01-v7.3-ksmbd-enable-tcp-keepalive-for-accepted-connections.patchaddtarget/linux/generic/backport-6.12/504-v7.3-ksmbd-fix-listener-task-lifetime-on-netdev-events.patchaddtarget/linux/generic/backport-6.18/504-v7.3-ksmbd-fix-listener-task-lifetime-on-netdev-events.patchedittarget/linux/generic/backport-6.12/503-02-v7.3-ksmbd-keep-tcp-timers-alive-for-kernel-sockets.patch
- scripts/make-sbom.py67eb69a1ae0a9defc6f08c14b2979ba67c000a421788767923000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comscripts: fix CycloneDX BOM version type
CycloneDX 1.4 requires the top-level BOM version to be an integer.
Emit numeric 1 so SBOMs generated from both APK and opkg package
indexes conform to the schema.
Signed-off-by: Cui Shuang <imcusg@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25059
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 09:58:43 +020067eb69a1ae0a9defc6f08c14b2979ba67c000a42scripts: fix CycloneDX BOM version typeeditscripts/make-sbom.py
- target/linux/qualcommax/dts/ipq8074-rbx850.dtsitarget/linux/qualcommax/dts/ipq8074-rbs850.dtstarget/linux/qualcommax/ipq807x/base-files/etc/board.d/02_networktarget/linux/qualcommax/dts/ipq8074-rbx750_850.dtsitarget/linux/qualcommax/dts/ipq8074-rbx750.dtsitarget/linux/qualcommax/image/netgear_rbx750.bootscripttarget/linux/qualcommax/dts/ipq8074-rbr850.dtstarget/linux/qualcommax/ipq807x/base-files/etc/hotplug.d/firmware/11-ath11k-caldatatarget/linux/qualcommax/ipq807x/base-files/lib/upgrade/platform.shtarget/linux/qualcommax/image/netgear_rbx750_850.bootscripttarget/linux/qualcommax/image/ipq807x.mkpackage/boot/uboot-tools/uboot-envtools/files/qualcommax_ipq807x0c5547e86515d992fe7d28c6986f7f59e94fb37f1788776618000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: ipq807x: add Netgear RBx850 support
Netgear RBx850 are tri band, 2.4GHz and 2x 5GHz, 12 stream 802.11ax mesh
devices from the Orbi series. The RBR850 is a router with a 2.5GbE WAN and
4 1GbE LAN ports. The RBS850 is a satellite without WAN port and half the
flash. The hardware is otherwise identical. They were sold in kits as
RBK852-RBK855, with one router and 1-4 satellites.
The RBx850 are substantially similar to the RBx750 so this commit factors
out a common DTS, flash script and build definition.
Hardware:
* SoC: Qualcomm IPQ8074
* RAM: 1GiB 2x Samsung 4A4G165WE-BCRC
* Flash: 512MiB Winbond W29N04GZ or 256MiB Winbond W29N02GZ
* WLAN 2.4GHz: QCN5024 4x4:4 b/g/n/ax
* WLAN 5GHz Low Band: QCN5054 4x4:4 a/n/ac/ax 5180-5320MHz
* WLAN 5GHz High Band: QCN5054 4x4:4 a/n/ac/ax 5500-5700MHz
* Ethernet: 4x 1GbE LAN, 1x 2.5GbE WAN on RBR850
* Serial Config: 3.3V TTL 115200-8-N-1, internal populated header
* Serial Layout: Bottom <- RX, TX, GND, 3.3V (don't connect) -> Top
* LEDs: green/red power, white/red/green/blue status
* Buttons: 1x Reset, 1x WPS
MAC addresses:
LAN1: Label
LAN2: Label + 1
LAN3: Label + 2
LAN4: Label + 3
WAN: Label + 1
2.4GHz: Label + 2 (RBR) or 1 (RBS)
5GHz-Low: Label + 3 (RBR) or 2 (RBS)
5GHz-High: Label + 4 (RBR) or 3 (RBS)
Flashing Notes:
The stock firmware images are signed. Both the bootloader and the stock
web interface check the signature and will fail to boot/flash.
The bootloader automatically does NMRP when a gigabit LAN connection is
present. The stock and factory images contain a U-Boot script that is
executed when flashing using NMRP. This is used to alter and persist the
U-Boot env with a boot command that works with unsigned firmware.
Install OpenWrt:
* Get the nmrpflash utility [0] and OpenWrt factory image
* Find network interface to use: nmrpflash -L
* Start nmrpflash: nmrpflash -i interface -f openwrt-...-factory.img
* Connect one of the device LAN ports to the same network using gigabit
* Plug the device in and wait for the bootloader to flash
* Unplug and replug the device once the power LED on the back blinks amber
Revert to Stock:
The boot command needs to be reverted before flashing the stock firmware,
otherwise it will fail to boot and get stuck in recovery mode (red power
LED flashing).
* Still in OpenWrt run: fw_setenv bootcmd bootipq
* Restart the device
* Flash the stock firmware RBx850-Va.b.c.d.img using nmrpflash
[0]: https://github.com/jclehner/nmrpflash
Authored by Michael Lotz.
Piotr Szczepanik:
* Cherry-picked the RBx850 support commit from openwrt/openwrt#22159
and adapted it to current main.
* Reworked the DTS networking changes for the current qualcommax
ipq807x device-tree style.
* Verified the RBx750 DTS split preserves the existing RBx750-specific
layout while moving shared RBx750/RBx850 nodes into a common DTSI.
Signed-off-by: Michael Lotz <mmlr@mlotz.ch>
Signed-off-by: Piotr Szczepanik <piter75@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24906
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 12:23:38 +02000c5547e86515d992fe7d28c6986f7f59e94fb37fqualcommax: ipq807x: add Netgear RBx850 supportaddtarget/linux/qualcommax/image/netgear_rbx750_850.bootscriptaddtarget/linux/qualcommax/dts/ipq8074-rbx750_850.dtsiedittarget/linux/qualcommax/dts/ipq8074-rbx750.dtsideletetarget/linux/qualcommax/image/netgear_rbx750.bootscriptedittarget/linux/qualcommax/ipq807x/base-files/etc/board.d/02_networkedittarget/linux/qualcommax/ipq807x/base-files/lib/upgrade/platform.shaddtarget/linux/qualcommax/dts/ipq8074-rbx850.dtsiedittarget/linux/qualcommax/image/ipq807x.mkaddtarget/linux/qualcommax/dts/ipq8074-rbr850.dtsedittarget/linux/qualcommax/ipq807x/base-files/etc/hotplug.d/firmware/11-ath11k-caldataaddtarget/linux/qualcommax/dts/ipq8074-rbs850.dtseditpackage/boot/uboot-tools/uboot-envtools/files/qualcommax_ipq807x
- package/firmware/ipq-wifi/Makefile74eb10ed5c61feff51f8d6ca6109b94e9c504ec11788776618000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comipq-wifi: update to Git HEAD (2026-08-26)
c9c7cd8142ac ipq8074: add Netgear RBK850 BDF
Signed-off-by: Piotr Szczepanik <piter75@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24906
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 12:23:38 +020074eb10ed5c61feff51f8d6ca6109b94e9c504ec1ipq-wifi: update to Git HEAD (2026-08-26)editpackage/firmware/ipq-wifi/Makefile
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.ca34ff932faaab80e9ec26f2cef98e896b8d09e471788789548000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: fix BPDU trapping and CPU transmission
The STP APP_CTRL rule uses 0x93fc for its third word. CMD occupies
bits 16:15 of that word, so this selects DROP (1), not the intended
REDIRECT_TO_CPU (3). Incoming BPDUs never reach the bridge protocol
implementation even though ordinary traffic continues to work.
Correcting only CMD exposes another issue: the 0x7f ingress port mask
includes CPU port 0. CPU-originated BPDUs are then trapped back to the
CPU rather than transmitted to the selected external port. Exclude
the CPU and SoC-specific loopback ports, deriving the remaining mask
from the port count. Use named fields for the third word so the action
and port selection are explicit.
On an AX3600/IPQ8074 running 6.18.44, register readback confirmed the
original rule. A guarded runtime test of 0x193fc restored BPDU reception
but captured locally generated BPDUs on the CPU RX path. With 0x193f4,
those RX reflections disappeared and the adjacent switch received
bridge protocol traffic again. Reapplying that value automatically
after a reboot established RSTP with the upstream root. The patched
driver also builds against the matching aarch64 kernel SDK.
IPQ6018's generated mask was checked, but not tested on hardware.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: OpenAI Codex
Signed-off-by: Jan Leon <Jan.gaschler@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25063
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 15:59:08 +0200a34ff932faaab80e9ec26f2cef98e896b8d09e47qualcommax: qca_ppe: fix BPDU trapping and CPU transmissionedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.hedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.h7b396007440c94f8e54fd2507c813571de170be61788790473000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: align define values
Align all macro replacement values in qca_ppe.h with the header's dominant tab stop.
This is a whitespace-only cleanup.
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 16:14:33 +02007b396007440c94f8e54fd2507c813571de170be6qualcommax: qca_ppe: align define valuesedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.h
- target/linux/generic/pending-6.12/770-08-net-phylink-link-the-PCS-list-before-the-initial-con.patchtarget/linux/generic/pending-6.18/737-10-net-phylink-link-the-PCS-list-before-the-initial-con.patch77824a92b83e300962d1635dc586b74820f8fc0d1788799060000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comgeneric: link the PCS list before the initial phylink config
A PCS taken from the phylink PCS list is attached to its phylink instance
in phylink_start(), after phylink_mac_initial_config() has already run
.pcs_config() on it, so that first call sees a NULL pcs->phylink. The
.mac_select_pcs() route has no such window: phylink_major_config() sets
pcs->phylink before it configures the PCS, which is what phylink did for
every PCS before the list existed.
DSA has no .mac_select_pcs, so every DSA port whose PCS comes from a
pcs-handle takes the list route. pcs-qca-uniphy reads the back-reference
in .pcs_config(), through phylink_expects_phy(), to tell a fixed link
from a PHY that simply does not negotiate in band, and a Zyxel NBG7815
panics on the wan port as netifd brings it up:
qca-ppe 3a000000.ppe wan: configuring for phy/2500base-x link mode
Unable to handle kernel access to user memory outside uaccess routines
at virtual address 0000000000000044
pc : phylink_expects_phy+0x0/0x38
lr : qca_uniphy_pcs_config_mode.isra.0+0x398/0x45c
Call trace:
phylink_expects_phy+0x0/0x38 (P)
qca_uniphy_pcs_config+0xec/0x13c
phylink_major_config+0x1e8/0x670
phylink_mac_initial_config+0xb8/0x14c
phylink_start+0x4c/0x280
dsa_port_enable_rt+0x48/0xb0
Its four psgmii ports come up first because psgmii has no in-band type at
all, which short-circuits the read, and its 10g port is managed in band.
Link the list where pl->pcs_state has just become PCS_STATE_STARTING, so
the guarantee holds on both routes. A .pcs_change() from a PCS that is
now linked earlier still resolves to nothing: phylink_run_resolve() does
nothing while phylink_disable_state holds PHYLINK_DISABLE_STOPPED, which
only the phylink_enable_and_run_resolve() below clears. The other two
phylink_mac_initial_config() callers are unaffected, both running with
the list already linked - phylink_resume() only takes that path when it
did not stop, and phylink_sfp_set_config() is gated on not being stopped.
The move rides in a patch of its own rather than an edit to the imported
737-02/770-02, so the imported series stays as it was taken. Both kernels
carry that series and both get the patch. No 6.12 target consumes the PCS
list today - the only in-tree filler lives under a files-6.18 directory
and every target that would use one is on 6.18 - so nothing there is
broken by the window; the two copies just have to stay the same patch.
Runtime tested on a Xiaomi AX3600 (IPQ8074, QCA8075 PSGMII, kernel 6.18):
the first .pcs_config() on every channel finds pcs->phylink set, at boot
and again after an admin down and up, which unlinks the list in
phylink_stop() and relinks it on the next start. The panic itself is not
reachable there, since psgmii has no in-band type and the resulting
PHYLINK_PCS_NEG_NONE short-circuits the read before it happens; that arm
runs on the NBG7815 in the report.
Fixes: 18cbd83a1443 ("generic: 6.18: import updated standalone PCS handling")
Link: https://github.com/JuliusBairaktaris/openwrt-nss-edma/issues/23
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 18:37:40 +020077824a92b83e300962d1635dc586b74820f8fc0dgeneric: link the PCS list before the initial phylink configaddtarget/linux/generic/pending-6.18/737-10-net-phylink-link-the-PCS-list-before-the-initial-con.patchaddtarget/linux/generic/pending-6.12/770-08-net-phylink-link-the-PCS-list-before-the-initial-con.patch
- target/linux/generic/pending-6.12/770-01-net-phylink-keep-and-use-MAC-supported_interfaces-in.patchtarget/linux/generic/pending-6.18/737-02-net-phylink-introduce-internal-phylink-PCS-handling.patchtarget/linux/generic/pending-6.18/737-01-net-phylink-keep-and-use-MAC-supported_interfaces-in.patchtarget/linux/generic/pending-6.12/770-02-net-phylink-introduce-internal-phylink-PCS-handling.patchtarget/linux/generic/pending-6.18/737-10-net-phylink-link-the-PCS-list-before-the-initial-con.patchtarget/linux/generic/backport-6.18/704-v7.3-net-phylink-treat-PSGMII-as-an-inband-capable-interface.patchtarget/linux/generic/pending-6.18/737-07-net-phylink-add-.pcs_link_down-PCS-OP.patchtarget/linux/generic/pending-6.12/706-net-phy-populate-host_interfaces-when-attaching-PHY.patchtarget/linux/generic/pending-6.12/770-05-net-phylink-support-late-PCS-provider-attach.patchtarget/linux/generic/pending-6.18/706-net-phy-populate-host_interfaces-when-attaching-PHY.patchtarget/linux/generic/pending-6.18/737-05-net-phylink-support-late-PCS-provider-attach.patchtarget/linux/generic/pending-6.12/770-03-net-phylink-add-phylink_release_pcs-to-externally-re.patchtarget/linux/generic/pending-6.18/737-03-net-phylink-add-phylink_release_pcs-to-externally-re.patchtarget/linux/generic/pending-6.12/770-08-net-phylink-link-the-PCS-list-before-the-initial-con.patchtarget/linux/generic/backport-6.12/704-v7.3-net-phylink-treat-PSGMII-as-an-inband-capable-interface.patchtarget/linux/generic/pending-6.12/770-07-net-phylink-add-.pcs_link_down-PCS-OP.patch2de0893dd23aae0be0eb44620e2ad271d739cd141788799061000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comgeneric: backport the phylink PSGMII in-band classification
phylink_get_inband_type() omits PHY_INTERFACE_MODE_PSGMII, so
phylink_pcs_neg_mode() returns early with PHYLINK_PCS_NEG_NONE for a
PSGMII port, and the in-band capabilities a PCS advertises are never
consulted: qca-uniphy answers pcs_inband_caps() with
LINK_INBAND_DISABLE | LINK_INBAND_ENABLE for every interface it drives,
PSGMII included.
Backport upstream commit 5ba017f9efef ("net: phylink: treat PSGMII as an
inband capable interface"), which classifies PSGMII as INBAND_CISCO_SGMII
beside SGMII and QSGMII and extends the generic clause 22 PCS helpers to
match, to both kernel copies the tree carries.
No board in the tree declares managed = "in-band-status" on a PSGMII
port, so every PSGMII port moves from PHYLINK_PCS_NEG_NONE to
PHYLINK_PCS_NEG_OUTBAND, PHY-managed and fixed links alike. A PCS
driver can distinguish the two with phylink_expects_phy() and force
its channel only on a fixed link.
The 6.12 copy adapts the phylink_mii_c22_pcs_decode_state() hunk, whose
SGMII case carries no neg_mode guard on that kernel.
Exercised on a Xiaomi AX3600 (IPQ8074, kernel 6.18), whose four ports are
PSGMII channels of one UNIPHY. With two of them declared as fixed links,
the channel force bit the qca-uniphy PCS drives reads 0 without this
patch and 1 with it, the channel speed field following the declared
speed, while the two channels still behind a PHY are untouched either
way. On the unmodified device tree nothing changes: every port links as
before and every channel register reads the value it held.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 18:37:41 +02002de0893dd23aae0be0eb44620e2ad271d739cd14generic: backport the phylink PSGMII in-band classificationedittarget/linux/generic/pending-6.12/706-net-phy-populate-host_interfaces-when-attaching-PHY.patchedittarget/linux/generic/pending-6.12/770-05-net-phylink-support-late-PCS-provider-attach.patchedittarget/linux/generic/pending-6.18/706-net-phy-populate-host_interfaces-when-attaching-PHY.patchedittarget/linux/generic/pending-6.18/737-03-net-phylink-add-phylink_release_pcs-to-externally-re.patchaddtarget/linux/generic/backport-6.18/704-v7.3-net-phylink-treat-PSGMII-as-an-inband-capable-interface.patchedittarget/linux/generic/pending-6.12/770-07-net-phylink-add-.pcs_link_down-PCS-OP.patchedittarget/linux/generic/pending-6.12/770-08-net-phylink-link-the-PCS-list-before-the-initial-con.patchedittarget/linux/generic/pending-6.18/737-07-net-phylink-add-.pcs_link_down-PCS-OP.patchedittarget/linux/generic/pending-6.18/737-10-net-phylink-link-the-PCS-list-before-the-initial-con.patchedittarget/linux/generic/pending-6.12/770-02-net-phylink-introduce-internal-phylink-PCS-handling.patchedittarget/linux/generic/pending-6.18/737-01-net-phylink-keep-and-use-MAC-supported_interfaces-in.patchedittarget/linux/generic/pending-6.18/737-05-net-phylink-support-late-PCS-provider-attach.patchedittarget/linux/generic/pending-6.12/770-03-net-phylink-add-phylink_release_pcs-to-externally-re.patchedittarget/linux/generic/pending-6.12/770-01-net-phylink-keep-and-use-MAC-supported_interfaces-in.patchaddtarget/linux/generic/backport-6.12/704-v7.3-net-phylink-treat-PSGMII-as-an-inband-capable-interface.patchedittarget/linux/generic/pending-6.18/737-02-net-phylink-introduce-internal-phylink-PCS-handling.patch
- target/linux/qualcommax/files/drivers/net/pcs/pcs-qca-uniphy.ctarget/linux/qualcommax/files/include/linux/pcs/pcs-qca-uniphy.h29c5542cd65f6ef8997090e0cf1e88129105d6461788799061000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: pcs: qca-uniphy: force the channel on every UNIPHY
A fixed link carries no in-band negotiation, so the UNIPHY channel has to
be told to take its speed from the channel register instead of waiting
for a word that never arrives. The driver does that only on IPQ5018 and
leaves a TODO for the other two SoCs.
There is nothing to work out for them: the SSDK writes the same bit on
all three. Its IPQ5018 path, adpt_mp_uniphy_mode_ctrl_set(), writes
newaddedfromhere_ch0_force_speed_25m through
hppe_uniphy_channel0_input_output_4_set(), and its IPQ6018/IPQ8074 path,
__adpt_hppe_uniphy_sgmii_mode_set(), writes the same field through
hppe_uniphy_channel0_force_speed_mode_set(), a wrapper around that same
accessor - UNIPHY_CH_CTRL bit 3, at the same offset on every generation.
The vendor condition, PHY_F_FORCE, comes from the port's forced-speed and
forced-duplex DT properties, which is a fixed link: what phylink reports
as an outband neg_mode with no PHY expected.
Drop the SoC test, and clear the bit for a port that is not a fixed link
as the vendor does, so a channel cannot keep a force left from an earlier
mode. The same function also serves USXGMII and 10GBASE-R, where the XPCS
drives the channel and UNIPHY_CH_CTRL is not the register in play - the
SSDK writes the bit only from its SGMII mode sets - so neither write is
made in those modes.
A forced channel then reads its speed from the SPEED_MODE field next to
that bit, which nothing ever wrote - the SSDK has an accessor for it and
no caller. It kept its 1000 Mbps reset value while pcs_link_up() moved
only the RX and TX clock rates, so a fixed link at 10 or 100 Mbps drove
the channel at the wrong speed. Program the field from the speed
pcs_link_up() is handed, in the encoding the receive path already decodes
out of the status register, and only for a channel the same predicate
reports as forced: an in-band channel carries its speed in the negotiated
word and leaves the field unread. 2500BASE-X has no encoding of its own -
SGMII+ carries the rate in the mode - and keeps the 1000 value the vendor
leaves there.
Exercised on a Xiaomi AX3600 (IPQ8074, kernel 6.18), whose four ports
share UNIPHY0. Behind a QCA8075 the clear leaves FORCE_MODE at 0 and
SPEED_MODE at its 1000 reset value, and a port linked at 100 Mbps holds
that value while its UNIPHY port clock follows the link down to 25 MHz,
so pcs_link_up() runs for the lower speed and leaves the field to the
in-band word. Channels of the same instance declared as fixed links read
back FORCE_MODE set with SPEED_MODE following the declared speed - 0 at
10 Mbps, 1 at 100 and 2 at 1000 - and the channels still behind a PHY
unchanged. The eleven IPQ5018 boards with a fixed link on a UNIPHY all
declare 1000 Mbps, the value the field already holds, so the speed half
is a latent defect there rather than a visible one, and no IPQ6018 or
IPQ8074 board in the tree has a fixed link on a UNIPHY at all.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 18:37:41 +020029c5542cd65f6ef8997090e0cf1e88129105d646qualcommax: pcs: qca-uniphy: force the channel on every UNIPHYedittarget/linux/qualcommax/files/drivers/net/pcs/pcs-qca-uniphy.cedittarget/linux/qualcommax/files/include/linux/pcs/pcs-qca-uniphy.h
- target/linux/qualcommax/dts/ipq8072-301w.dts3b35c7074a2d08bb55fa009699962b3726aea6c41788800549000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: ipq807x: 301w: read the port MAC addresses from ART
The board names its six ports through ethernetN aliases for the bootloader
to patch an address into, and since the PPE conversion only the first two
arrive. On r35301-d47ce71a89, the last snapshot before it, every port came
up on an address of its own; on r35323-7ff96bf05c, the first one after,
lan1, lan2, 10g-1 and 10g-2 have none and inherit the conduit's, so four
ports and the bridge above them all answer to one MAC.
The addresses the bootloader hands out come from the MAC table at the start
of 0:art, one 6-byte slot per ethernetN alias. Describe those slots, so the
ports can read them whatever the bootloader does. ipq8071-ax3600.dtsi
describes its own ART table the same way.
The mapping is confirmed on a 301w: the table holds 24:5e:be:55:69:32
through :37 in slots 0 to 5 and nothing else, and the pre-conversion
snapshot brought up each port on the slot its alias names - lan4 on :32,
lan3 :33, lan2 :34, lan1 :35, 10g-1 :36, 10g-2 :37.
of_get_mac_address() consults the DT properties before the nvmem cell, so
a port the bootloader patched keeps the address it has.
Fixes: f50435627d37 ("qualcommax: ipq60xx/ipq807x: convert to PPE networking stack")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24528
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-07 19:02:29 +02003b35c7074a2d08bb55fa009699962b3726aea6c4qualcommax: ipq807x: 301w: read the port MAC addresses from ARTedittarget/linux/qualcommax/dts/ipq8072-301w.dts
- target/linux/mediatek/patches-6.18/197-arm64-dts-mediatek-mt7986-correct-timer-frequency.patchf36067d4e9c2e2a71b466a19ce4211e4d4a392281788819753000https://taiha.net/jenkins/user/danieldanieldaniel@makrotopia.orgmediatek: correct MT7986 system timer rate
Port MediaTek commit 6a4c41c41410 ("fix timer inaccurate"), which
corrects the architected timer rate from 13 MHz to 12,986,200 Hz in the
DTS files for both MT7986A and MT7986B.
Upstream mt7986b.dtsi includes mt7986a.dtsi, so add the corrected rate
once to the common timer node. This makes the architected timer driver
override the 13 MHz value reported by firmware through CNTFRQ_EL0 for
both SoC variants.
The resulting 1062 ppm discrepancy exceeds the kernel's 500 ppm NTP
correction limit. This matches reports of sysntpd remaining saturated at
+500 ppm on the GL-MT6000.
Link: https://github.com/mediatek/mtk-openwrt-feeds/commit/6a4c41c41410cd5042ad10c39da6593ba036283c
Link: https://github.com/openwrt/openwrt/issues/24789
Signed-off-by: Andrea Pesaresi <andreapesaresi82@gmail.com>
2026-09-07 23:22:33 +0100f36067d4e9c2e2a71b466a19ce4211e4d4a39228mediatek: correct MT7986 system timer rateaddtarget/linux/mediatek/patches-6.18/197-arm64-dts-mediatek-mt7986-correct-timer-frequency.patch
- target/linux/econet/patches-6.18/044-16-v7.3-pinctrl-airoha-fix-edge-triggered-interrupts-han.patchtarget/linux/econet/patches-6.18/044-06-v7.3-pinctrl-airoha-fix-I2C1-pin-mux-config-for-AN758.patchtarget/linux/econet/patches-6.18/044-18-v7.3-pinctrl-airoha-statically-allocate-gpio-regs-str.patchtarget/linux/econet/patches-6.18/044-19-v7.3-pinctrl-airoha-move-common-definitions-to-the-se.patchtarget/linux/econet/patches-6.18/044-21-v7.3-pinctrl-airoha-an7581-remove-en7581-prefix-from-.patchtarget/linux/econet/patches-6.18/044-23-v7.3-pinctrl-airoha-an7583-rename-registers-to-match-.patchtarget/linux/econet/patches-6.18/042-03-v6.19-pinctrl-airoha-add-support-for-Airoha-AN7583-PINs.patchtarget/linux/econet/patches-6.18/044-12-v7.3-pinctrl-airoha-minor-improvements.patchtarget/linux/econet/patches-6.18/043-09-v7.2-pinctrl-airoha-an7583-add-missed-gpio22-pin-group.patchtarget/linux/econet/patches-6.18/044-07-v7.3-pinctrl-airoha-fix-I2C-pin-mux-config-for-AN7583.patchtarget/linux/econet/patches-6.18/043-05-v7.2-pinctrl-airoha-an7581-fix-incorrect-led-mapping-in-p.patchtarget/linux/econet/patches-6.18/043-04-v7.2-pinctrl-airoha-an7583-fix-misprint-in-gpio19-pinconf.patchtarget/linux/econet/patches-6.18/044-28-v7.3-pinctrl-airoha-try-to-find-chip-scu-node-by-phan.patchtarget/linux/econet/patches-6.18/044-02-v7.3-pinctrl-airoha-an7581-fix-pinconf-of-i2c_scl-i2c.patchtarget/linux/econet/patches-6.18/044-11-v7.3-pinctrl-airoha-add-set_direction-helper-for-gpio.patchtarget/linux/econet/patches-6.18/044-13-v7.3-pinctrl-airoha-fix-getting-gpiochip-pinctrl-poin.patchtarget/linux/econet/patches-6.18/044-22-v7.3-pinctrl-airoha-an7583-remove-an7583-prefix-from-.patchtarget/linux/econet/patches-6.18/043-10-v7.2-pinctrl-airoha-an7583-fix-phy1_led1-pin-function.patchtarget/linux/econet/patches-6.18/043-11-v7.2-pinctrl-airoha-an7583-remove-undefined-groups-from-p.patchtarget/linux/econet/patches-6.18/042-01-v6.19-pinctrl-airoha-convert-PHY-LED-GPIO-to-macro.patchtarget/linux/econet/patches-6.18/044-15-v7.3-pinctrl-airoha-fix-IRQ-mask-unmask-code.patchtarget/linux/econet/patches-6.18/044-24-v7.3-pinctrl-airoha-an7583-add-support-for-npu_uart-p.patchtarget/linux/econet/patches-6.18/043-01-v7.2-pinctrl-airoha-Fix-type-in-.pin_config_group_get-cal.patchtarget/linux/econet/patches-6.18/044-05-v7.3-pinctrl-airoha-an7583-fix-muxing-of-non-gpio-def.patchtarget/linux/econet/patches-6.18/043-03-v7.2-pinctrl-airoha-an7583-add-missed-gpio32-pin-group.patchtarget/linux/econet/patches-6.18/044-20-v7.3-pinctrl-airoha-split-driver-on-shared-code-and-S.patchtarget/linux/econet/patches-6.18/044-10-v7.3-pinctrl-airoha-add-missed-get_direction-function.patchtarget/linux/econet/patches-6.18/043-07-v7.2-pinctrl-airoha-fix-pwm-pin-function-for-an7581-and-a.patchtarget/linux/econet/patches-6.18/044-04-v7.3-pinctrl-airoha-an7581-fix-mux-conf-of-pcie_reset.patchtarget/linux/econet/patches-6.18/044-14-v7.3-pinctrl-airoha-add-missed-IRQ-resource-helpers.patchtarget/linux/econet/patches-6.18/043-02-v7.2-pinctrl-Move-Airoha-driver-to-dedicated-directory.patchtarget/linux/econet/patches-6.18/044-25-v7.3-pinctrl-airoha-an7583-add-support-for-pon_alt-pi.patchtarget/linux/econet/patches-6.18/042-04-v6.19-pinctrl-airoha-Fix-AIROHA_PINCTRL_CONFS_DRIVE_E2.patchtarget/linux/econet/patches-6.18/043-06-v7.2-pinctrl-airoha-an7583-fix-incorrect-led-mapping-in-p.patchtarget/linux/econet/patches-6.18/044-26-v7.3-pinctrl-airoha-an7583-add-support-for-olt-pinmux.patchtarget/linux/econet/patches-6.18/044-08-v7.3-pinctrl-airoha-fix-AN7583-MDIO-pin-mux-config.patchtarget/linux/econet/patches-6.18/044-27-v7.3-pinctrl-airoha-add-support-of-en7523-SoC.patchtarget/linux/econet/patches-6.18/044-03-v7.3-pinctrl-airoha-an7583-fix-I2C0_SDA_PD-register-b.patchtarget/linux/econet/patches-6.18/043-08-v7.2-pinctrl-airoha-an7583-fix-gpio21-pin-group.patchtarget/linux/econet/patches-6.18/044-17-v7.3-pinctrl-airoha-remove-not-needed-irq_type-array.patchtarget/linux/econet/patches-6.18/044-01-v7.3-pinctrl-airoha-fix-mdio-bitfield-names.patchtarget/linux/econet/patches-6.18/042-02-v6.19-pinctrl-airoha-convert-PWM-GPIO-to-macro.patchtarget/linux/econet/patches-6.18/044-09-v7.3-pinctrl-airoha-an7583-fix-spi-group-pins.patchtarget/linux/econet/patches-6.18/042-05-v6.19-pinctrl-airoha-convert-comma-to-semicolon.patch43073ac09b0767eab4816fe1c5db0e39fdfc985e1788853893000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.deeconet: copy Airoha pinctrl backports from the airoha target
The EN7528 pin controller support that follows needs the Airoha pinctrl
driver in its v7.3 shape: moved out of drivers/pinctrl/mediatek into its
own directory and split into shared code plus per-SoC drivers.
The airoha target already carries that whole chain for 6.18, so copy the
patches from there.
No functional change.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25013
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-08 09:51:33 +020043073ac09b0767eab4816fe1c5db0e39fdfc985eeconet: copy Airoha pinctrl backports from the airoha targetaddtarget/linux/econet/patches-6.18/044-22-v7.3-pinctrl-airoha-an7583-remove-an7583-prefix-from-.patchaddtarget/linux/econet/patches-6.18/042-05-v6.19-pinctrl-airoha-convert-comma-to-semicolon.patchaddtarget/linux/econet/patches-6.18/043-05-v7.2-pinctrl-airoha-an7581-fix-incorrect-led-mapping-in-p.patchaddtarget/linux/econet/patches-6.18/042-02-v6.19-pinctrl-airoha-convert-PWM-GPIO-to-macro.patchaddtarget/linux/econet/patches-6.18/044-10-v7.3-pinctrl-airoha-add-missed-get_direction-function.patchaddtarget/linux/econet/patches-6.18/044-20-v7.3-pinctrl-airoha-split-driver-on-shared-code-and-S.patchaddtarget/linux/econet/patches-6.18/044-25-v7.3-pinctrl-airoha-an7583-add-support-for-pon_alt-pi.patchaddtarget/linux/econet/patches-6.18/044-03-v7.3-pinctrl-airoha-an7583-fix-I2C0_SDA_PD-register-b.patchaddtarget/linux/econet/patches-6.18/043-11-v7.2-pinctrl-airoha-an7583-remove-undefined-groups-from-p.patchaddtarget/linux/econet/patches-6.18/043-09-v7.2-pinctrl-airoha-an7583-add-missed-gpio22-pin-group.patchaddtarget/linux/econet/patches-6.18/044-04-v7.3-pinctrl-airoha-an7581-fix-mux-conf-of-pcie_reset.patchaddtarget/linux/econet/patches-6.18/044-09-v7.3-pinctrl-airoha-an7583-fix-spi-group-pins.patchaddtarget/linux/econet/patches-6.18/043-08-v7.2-pinctrl-airoha-an7583-fix-gpio21-pin-group.patchaddtarget/linux/econet/patches-6.18/044-06-v7.3-pinctrl-airoha-fix-I2C1-pin-mux-config-for-AN758.patchaddtarget/linux/econet/patches-6.18/044-18-v7.3-pinctrl-airoha-statically-allocate-gpio-regs-str.patchaddtarget/linux/econet/patches-6.18/043-01-v7.2-pinctrl-airoha-Fix-type-in-.pin_config_group_get-cal.patchaddtarget/linux/econet/patches-6.18/043-10-v7.2-pinctrl-airoha-an7583-fix-phy1_led1-pin-function.patchaddtarget/linux/econet/patches-6.18/044-12-v7.3-pinctrl-airoha-minor-improvements.patchaddtarget/linux/econet/patches-6.18/044-23-v7.3-pinctrl-airoha-an7583-rename-registers-to-match-.patchaddtarget/linux/econet/patches-6.18/044-08-v7.3-pinctrl-airoha-fix-AN7583-MDIO-pin-mux-config.patchaddtarget/linux/econet/patches-6.18/044-17-v7.3-pinctrl-airoha-remove-not-needed-irq_type-array.patchaddtarget/linux/econet/patches-6.18/042-04-v6.19-pinctrl-airoha-Fix-AIROHA_PINCTRL_CONFS_DRIVE_E2.patchaddtarget/linux/econet/patches-6.18/044-13-v7.3-pinctrl-airoha-fix-getting-gpiochip-pinctrl-poin.patchaddtarget/linux/econet/patches-6.18/044-21-v7.3-pinctrl-airoha-an7581-remove-en7581-prefix-from-.patchaddtarget/linux/econet/patches-6.18/044-05-v7.3-pinctrl-airoha-an7583-fix-muxing-of-non-gpio-def.patchaddtarget/linux/econet/patches-6.18/043-02-v7.2-pinctrl-Move-Airoha-driver-to-dedicated-directory.patchaddtarget/linux/econet/patches-6.18/044-01-v7.3-pinctrl-airoha-fix-mdio-bitfield-names.patchaddtarget/linux/econet/patches-6.18/044-14-v7.3-pinctrl-airoha-add-missed-IRQ-resource-helpers.patchaddtarget/linux/econet/patches-6.18/044-19-v7.3-pinctrl-airoha-move-common-definitions-to-the-se.patchaddtarget/linux/econet/patches-6.18/043-04-v7.2-pinctrl-airoha-an7583-fix-misprint-in-gpio19-pinconf.patchaddtarget/linux/econet/patches-6.18/044-02-v7.3-pinctrl-airoha-an7581-fix-pinconf-of-i2c_scl-i2c.patchaddtarget/linux/econet/patches-6.18/044-07-v7.3-pinctrl-airoha-fix-I2C-pin-mux-config-for-AN7583.patchaddtarget/linux/econet/patches-6.18/044-26-v7.3-pinctrl-airoha-an7583-add-support-for-olt-pinmux.patchaddtarget/linux/econet/patches-6.18/044-11-v7.3-pinctrl-airoha-add-set_direction-helper-for-gpio.patchaddtarget/linux/econet/patches-6.18/043-03-v7.2-pinctrl-airoha-an7583-add-missed-gpio32-pin-group.patchaddtarget/linux/econet/patches-6.18/044-16-v7.3-pinctrl-airoha-fix-edge-triggered-interrupts-han.patchaddtarget/linux/econet/patches-6.18/042-03-v6.19-pinctrl-airoha-add-support-for-Airoha-AN7583-PINs.patchaddtarget/linux/econet/patches-6.18/044-27-v7.3-pinctrl-airoha-add-support-of-en7523-SoC.patchaddtarget/linux/econet/patches-6.18/044-28-v7.3-pinctrl-airoha-try-to-find-chip-scu-node-by-phan.patchaddtarget/linux/econet/patches-6.18/042-01-v6.19-pinctrl-airoha-convert-PHY-LED-GPIO-to-macro.patchaddtarget/linux/econet/patches-6.18/043-06-v7.2-pinctrl-airoha-an7583-fix-incorrect-led-mapping-in-p.patchaddtarget/linux/econet/patches-6.18/043-07-v7.2-pinctrl-airoha-fix-pwm-pin-function-for-an7581-and-a.patchaddtarget/linux/econet/patches-6.18/044-15-v7.3-pinctrl-airoha-fix-IRQ-mask-unmask-code.patchaddtarget/linux/econet/patches-6.18/044-24-v7.3-pinctrl-airoha-an7583-add-support-for-npu_uart-p.patch
- target/linux/econet/patches-6.18/045-01-v7.4-pinctrl-airoha-limit-GPIO-interrupts-to-interrup.patchtarget/linux/econet/dts/en7528_dasan_h660gm-a-generic.dtstarget/linux/econet/dts/en7528.dtsitarget/linux/econet/dts/en7528_jiofiber.dtsitarget/linux/econet/dts/en7528_dasan_h660gm-a-airtel.dtstarget/linux/econet/patches-6.18/102-pinctrl-airoha-fix-setting-of-GPIO-direction.patchtarget/linux/econet/patches-6.18/044-29-v7.3-pinctrl-airoha-add-support-of-an7563-SoC.patchtarget/linux/econet/dts/en7528_jiofiber_jcow407.dtstarget/linux/econet/en7528/config-6.18target/linux/econet/dts/en7528_dasan_h660gm-a.dtsitarget/linux/econet/patches-6.18/045-03-v7.4-pinctrl-airoha-add-support-of-en7528-SoC.patchtarget/linux/econet/dts/en7528_jiofiber_jcow414.dtstarget/linux/econet/patches-6.18/045-02-v7.4-dt-bindings-pinctrl-Add-EcoNet-EN7528-pin-contro.patch23aaf320ade912fc128070f562182a4c380718ec1788853894000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.deeconet: en7528: add pin controller support
Backport the EN7528 pin controller, accepted upstream for v7.4:
pinctrl: airoha: limit GPIO interrupts to interrupt-capable pins
dt-bindings: pinctrl: Add EcoNet EN7528 pin controller
pinctrl: airoha: add support of en7528 SoC
The AN7563 driver from v7.3 comes along because the first of those
touches it, and a not yet upstream fix for the GPIO direction bits is
added on top. That one clears both bits of the two bit GPIO_CTRL field
instead of only the LSB, so a bootloader leaving the reserved value
behind no longer keeps the pin from driving.
Only GPIO0-GPIO15 are wired to the interrupt controller, and
gpiod_to_irq() now fails for the others rather than handing out an
interrupt that can never fire. Split the buttons accordingly: those
below GPIO16 become interrupt driven gpio-keys, the rest stay in a
gpio-keys-polled node.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25013
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-08 09:51:34 +020023aaf320ade912fc128070f562182a4c380718ececonet: en7528: add pin controller supportaddtarget/linux/econet/patches-6.18/102-pinctrl-airoha-fix-setting-of-GPIO-direction.patchaddtarget/linux/econet/patches-6.18/045-02-v7.4-dt-bindings-pinctrl-Add-EcoNet-EN7528-pin-contro.patchedittarget/linux/econet/dts/en7528_jiofiber_jcow407.dtsedittarget/linux/econet/dts/en7528.dtsiedittarget/linux/econet/dts/en7528_dasan_h660gm-a-airtel.dtsedittarget/linux/econet/dts/en7528_dasan_h660gm-a-generic.dtsedittarget/linux/econet/dts/en7528_jiofiber.dtsiedittarget/linux/econet/en7528/config-6.18addtarget/linux/econet/patches-6.18/044-29-v7.3-pinctrl-airoha-add-support-of-an7563-SoC.patchedittarget/linux/econet/dts/en7528_jiofiber_jcow414.dtsaddtarget/linux/econet/patches-6.18/045-01-v7.4-pinctrl-airoha-limit-GPIO-interrupts-to-interrup.patchedittarget/linux/econet/dts/en7528_dasan_h660gm-a.dtsiaddtarget/linux/econet/patches-6.18/045-03-v7.4-pinctrl-airoha-add-support-of-en7528-SoC.patch
- tools/erofs-utils/Makefilef3f427048a8828f61270add14a113d70610d09b21788854974000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comtools: erofs-utils: update to 1.9.4
ChangeLog:
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/ChangeLog?h=v1.9.4
Build system: x86/64
Tested on: x86/64
Signed-off-by: Andy Chiang <AndyChiang_git@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24991
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-08 10:09:34 +0200f3f427048a8828f61270add14a113d70610d09b2tools: erofs-utils: update to 1.9.4edittools/erofs-utils/Makefile
- target/linux/qualcommax/files/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq5018.c098e599864fa070916d2f6c39e6f2ec8b0173c621788857775000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: ipq50xx: add 1000Base-X for Qualcomm IPQ5018 DWMAC driver
1000Base-X is supported by UNIPHY but missing from IPQ5018 DWMAC driver.
Add it back.
Verified with YT9215.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25052
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-08 10:56:15 +0200098e599864fa070916d2f6c39e6f2ec8b0173c62qualcommax: ipq50xx: add 1000Base-X for Qualcomm IPQ5018 DWMAC driveredittarget/linux/qualcommax/files/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq5018.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_scheduler.c73c6d07df9bb37a5775d73920cadab4fb56eec5c1788872589000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: fix CPPE BM TDM schedule
The CPPE buffer manager TDM table contains 98 entries, while the
SSDK cppe_port_tdm0_tbl has 96. The first 96 entries match exactly; the
trailing CPU ingress and egress pair duplicates the beginning of the
circular schedule and makes ARRAY_SIZE program a depth of 98.
Drop the duplicate pair so the schedule and depth match SSDK.
Link: https://github.com/openwrt/openwrt/pull/24203#issuecomment-5446469623
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-08 15:03:09 +020073c6d07df9bb37a5775d73920cadab4fb56eec5cqualcommax: qca_ppe: fix CPPE BM TDM scheduleedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_scheduler.c
- target/linux/generic/files/drivers/platform/mikrotik/Kconfigtarget/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c7161fa5814480304b5a3143d0549735cff26ca061788884449000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comgeneric: mikrotik: expose preboot etherboot settings in rb_softconfig
RouterBOOT can be told to look for a netboot server for a few seconds
before falling through to the configured boot device, optionally
restricted to a single Netinstall server. RouterOS calls these
preboot-etherboot and preboot-etherboot-server. Neither was modelled
here, so on a board running Linux rather than RouterOS they could not be
read or changed at all.
That matters most on a board where Linux has replaced RouterOS: without
these, the only way to arrange a netboot is boot_device=ethonce, which
is one-shot and must be rewritten before every attempt. preboot-etherboot
is persistent, needs no write per boot, and still falls through to the
boot device when no server answers.
Add both:
preboot_etherboot tag 0x24, 0..30 seconds, zero disabling the wait
preboot_etherboot_server tag 0x25, an IPv4 address, 0.0.0.0 for any
RouterBOOT has no interactive presentation of either setting to mimic:
neither appears in its setup menu, and both can only be written from
RouterOS. Rather than borrow the "disabled" and "any" keywords RouterOS
uses for zero, present both tags as they are stored. RouterOS rejects a
timeout of 31, which is where the upper bound comes from.
Note the server address is stored in network byte order, unlike every
other tag in this record, which is a little-endian u32. 192.168.1.142 is
held as c0 a8 01 8e, so reading it as a u32 would yield 142.1.168.192 -
a valid-looking address pointing at a different host.
Verified on a MikroTik E50UG (hEX refresh):
- the show path decodes a server address written by RouterOS 7.24.2
- a write of 10.20.30.40 lands in flash as 0a 14 1e 28
- out-of-range timeouts and malformed addresses are rejected
- with preboot_etherboot set to 5 from Linux and boot_device left at
flasheth, RouterBOOT netboots; set back to zero, it boots from NAND
Both tag numbers were confirmed by diffing the soft_config record before
and after changing each setting from RouterOS. They have not been
cross-checked against other MikroTik hardware.
Signed-off-by: Matt Eaton <git@divinehawk.com>
Link: https://github.com/openwrt/openwrt/pull/25044
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-08 18:20:49 +02007161fa5814480304b5a3143d0549735cff26ca06generic: mikrotik: expose preboot etherboot settings in rb_softconfigedittarget/linux/generic/files/drivers/platform/mikrotik/Kconfigedittarget/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
- package/network/services/dnsmasq/Makefilepackage/network/services/dnsmasq/files/dnsmasq.initacde2ff93ec1c2d234011ae246e3a0f1038cd2ec1788885320000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comdnsmasq: add bare hostname for static leases
Static DHCP entries with dns enabled only had
their FQDN written to the generated hosts file, so
the bare hostname would not resolve unless the host also had
an active DHCP lease:
$ dig +short dockbox-vm
$ dig +short dockbox-vm.lan
10.100.1.20
Signed-off-by: Tucker Kern <tuckkern@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25012
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-08 18:35:20 +0200acde2ff93ec1c2d234011ae246e3a0f1038cd2ecdnsmasq: add bare hostname for static leaseseditpackage/network/services/dnsmasq/files/dnsmasq.initeditpackage/network/services/dnsmasq/Makefile
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.c918c72d210a977e6965491cde3b75a6cc309844a1788888628000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl930x: mask the PIE action VID/act fields before shifting
rtl930x_write_pie_action() built the ivid_act, ivid_data and ovid_act
fields of the PIE action with the mask applied *after* the shift:
r[15] |= ((u32)(pr->ivid_data) << 9) & 0xfff;
so only the low three bits of a 12-bit assigned VID survived - e.g. an
"action vlan push id 100" was programmed as VID 4, id 254 as VID 6 -
while ivid_act / ovid_act were masked to zero and never took effect.
ovid_data was already done the right way round.
Mask each field to its width and then shift it into place, matching
ovid_data and the rest of the function.
Verified on an RTL9300 (Zyxel XGS1210-12): with an ingress cls_flower
rule carrying "action vlan push id <N>", the PIE action now encodes the
requested VID (100 / 254 / 4094 read back exactly from r[15], where the
old code produced 4 / 6 / 6), and a matching frame leaves the CPU port
tagged with that VID (confirmed by tcpdump against a no-rule control).
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25070
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 19:30:28 +0200918c72d210a977e6965491cde3b75a6cc309844arealtek: dsa: rtl930x: mask the PIE action VID/act fields before shiftingedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c3c17984e3a7fc6a9cf516090f7a52f10f61521431788888628000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: rework packet counter alloc, add a free helper
rtl83xx_packet_cntr_alloc() had no counterpart: the L3 route path
open-codes the release as a bare set_bit() on packet_cntr_use_bm, which
only frees the 32-bit half and leaves the enclosing 64-bit octet block
marked used forever.
Rename it to rtldsa_packet_cntr_alloc() (rtldsa_ prefix convention),
bound the bitmap scans by n_counters, take reg_mutex with scoped_guard()
and use the non-atomic __*_bit() ops now that it all runs under the lock,
and add rtldsa_packet_cntr_free(): it ignores a double release, marks the
counter free and, once both halves of its octet block are free, returns
the block to the octet pool.
Switch the L3 route teardown to the helper; no functional change there
beyond also releasing the octet block.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25070
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 19:30:28 +02003c17984e3a7fc6a9cf516090f7a52f10f6152143realtek: dsa: rtl83xx: rework packet counter alloc, add a free helperedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.hedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.cc3007f24a6bc10e15612fb51fb74e52f315180a91788888628000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: fix rtl83xx_configure_flower() error unwinding
On any failure after the flow was inserted into the hashtable
rtl83xx_configure_flower() returned straight away, leaking the flow and
leaving a dangling entry in tc_ht. The RCU section around the duplicate
lookup also used a goto label for no reason.
Drop the RCU reference right after the lookup, and unwind through
out_remove / out_free so a failed rtl83xx_add_flow() or pie_rule_add()
removes the entry and frees the flow. Also propagate rtl83xx_add_flow()'s
return value, which was previously ignored, and log the insert failure
with dev_err().
pie_rule_add() can fail after rtldsa_packet_cntr_alloc() has handed out a
packet counter, so release it with rtldsa_packet_cntr_free() from the
out_remove path. kzalloc() leaves rule.packet_cntr at 0, a valid counter
id, so initialise it to -1 and let the helper skip a negative id.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25070
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 19:30:28 +0200c3007f24a6bc10e15612fb51fb74e52f315180a9realtek: dsa: rtl83xx: fix rtl83xx_configure_flower() error unwindingedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c9d3500939a7bb390c641f2a6cc0a9435e5648a3f1788888629000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: validate tc flower match keys and actions
rtl83xx_parse_flow_rule() accepted whatever it was handed: unknown
dissector keys were ignored, partial EtherType / ip_proto / VLAN masks
were treated as exact, the ip_proto decoding set frame_type_l4 twice for
TCP and never for a UDP-only match, and its return value was dropped with
a "TODO: check error".
Reject what the PIE cannot express before programming it:
- fail on dissector keys outside the supported set, and on a rule
combining IPv4 and IPv6 addresses;
- require a full 0xffff EtherType mask and a full 0xff ip_proto mask,
decode ip_proto through a switch (adding IGMP), and bail on anything
else;
- reject VLAN priority / DEI / ethertype sub-matches, and a VLAN TPID
other than 802.1Q (cls_flower always sets a full vlan_tpid mask, so
an unconditional reject would kill the VLAN match arm);
- add rtldsa_validate_flow_actions() to accept only drop / trap /
redirect / mirred - FLOW_ACTION_VLAN_PUSH / _POP included in the
rejection, the ivid / ovid PIE translation in rtl83xx_add_flow() is
neither programmed nor tested through this offload - honour control
flags and the hw-stats type, and propagate the parse and action
errors out of rtl83xx_add_flow().
Unknown EtherTypes are rejected here; generic EtherType matching arrives
with the cls_flower offload series (openwrt/openwrt#24994), which rebases
on top of this.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25070
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 19:30:29 +02009d3500939a7bb390c641f2a6cc0a9435e5648a3frealtek: dsa: rtl83xx: validate tc flower match keys and actionsedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.c870c10eb8f8cfaa41960438290aaa637e5fb65621788891538000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: drop an unused read in the LAG track map
rtldsa_930x_lag_set_port2group() and rtldsa_931x_lag_set_port2group()
read the SRC_TRK_MAP entry before writing it, but neither looks at what
came back, and the entry is one register wide on both SoCs, so the
write that follows replaces all of it.
The width is Realtek's own: the GPL SDK table lists give SRC_TRK_MAP as
access type 8 with one data register on RTL9300, and type 13 with one
data register on RTL9310 (src/hal/chipdef/longan/rtk_longan_table_list.c
and .../mango/rtk_mango_table_list.c).
The value written is unchanged; what goes is one table transaction per
affected port, since the caller walks every port a membership change
touches.
Compile-tested on realtek/rtl930x. Not run on hardware.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25062
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 20:18:58 +0200870c10eb8f8cfaa41960438290aaa637e5fb6562realtek: dsa: drop an unused read in the LAG track mapedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/Makefiletarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.c11ee1eed06a2c4326709e424b606aaa8a283a0cf1788891538000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: table: separate table access from DSA
The Otto SoCs reach most of their switch state through indirect table
access: a command word carrying table, index and direction goes into
one register, and the entry itself appears in a window of data
registers. That mechanism is not layer 2 and has no natural home in a
DSA driver; it sits in common.c only because DSA happens to be its
first consumer.
Move the descriptor array, struct table_reg and the rtl_table_*
functions verbatim into table.c and table.h. Nothing is renamed and no
line of the implementation changes; rtl-otto.h includes the new header,
so every consumer compiles unchanged.
The consumers already called these symbols externally, so relocating
the definitions only moves them from common.o to table.o. Built for
realtek/rtl930x before and after: rtl838x.o, rtl839x.o, rtl930x.o,
rtl931x.o and l3.o are identical once debug sections are stripped, and
common.o loses 1536 bytes of code and data, 1004 of text and 532 of
data. The raw objects do differ,
because CONFIG_DEBUG_INFO records line numbers from rtl-otto.h.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25062
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 20:18:58 +020011ee1eed06a2c4326709e424b606aaa8a283a0cfrealtek: table: separate table access from DSAedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.haddtarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.hedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/Makefileaddtarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl839x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl838x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.c9f62ca8ff14d701928b425b53d0093de80eb0df61788891538000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: table: read and write whole table entries
Table access hands the caller a register address and lets it do its own
MMIO, so reading one entry looks like this:
struct table_reg *q = rtl_table_get(RTL8380_TBL_L2, 0);
rtl_table_read(q, idx);
for (int i = 0; i < 3; i++)
r[i] = sw_r32(rtl_table_data(q, i));
rtl_table_release(q);
The driver has 89 of those sequences and computes a data register
address 205 times. Move the register access into the table code, name
each table after itself rather than after the register and type value
that select it, and let the caller pass a buffer:
otto_table_read(RTL8380_TBL_L2_UC, idx, &r);
The names, the width of an entry and the number of rows are Realtek's
own, taken from the table lists in the GPL SDK
(src/hal/chipdef/<chip>/rtk_<chip>_table_list.c), with the register a
table belongs to taken from the access group its <soc>_table_read()
selects. Tables sharing a type value are one set of rows decoded in
different layouts; each keeps its own name and its own width, because
on five of the thirteen shared slots the width differs. The four
RTL9300 host route tables are the one place where the SDK count is not
the bound: they hold six entries in every eight addresses, and l3.c
translates before it calls, so the map carries the 8192 of the address
space rather than the 6144 entries.
A caller names a table by its id and gets back a handle, an int
indexing the driver's own data. Ids start at 1000 and handles at 0, so
passing one where the other belongs is refused rather than quietly
accepted.
#define otto_table_read(id, idx, p) \
otto_table_read_bytes((id), (idx), (p), otto_table_size(p))
moves a whole entry and covers every caller. otto_table_size() takes
the length from the caller's own object, so a buffer narrower than the
table can no longer be overrun, where before the transfer length was a
literal repeated at each call site and tied to nothing. A bare array is
refused at compile time, and TBL_MAP() asserts every width against the
window of the register it sits on, so a table wider than its window
cannot be described at all.
An index outside the table is refused. The mask the command register
applies to it cannot stand in for that check: the field is wider than
the table on 66 of the 104 and exactly as wide on the other 38, and six
tables do not have a power-of-two row count at all. The refusal carries
a WARN_ONCE; the splat is one-shot, the refusal is not. No index a
shipping image can produce reaches the row count of the table it names:
the paths that could are in the RTL930x L3 offload, which no subtarget
config enables, and they predate this series.
Both read entry points clear their output first, since no caller looks
at a return value. __otto_table_read_bytes() clears the caller's
buffer, and __otto_table_fetch(), whose output is the data window
itself, clears that window before the command. A refused read then
hands back zeroes rather than the caller's stack or the row a previous
transaction left behind. A timeout still copies the window, so that a
read-modify-write commits the row as the hardware left it.
The window clear is new register traffic on RTL931x, its only user: 53
writes per standard counter fetch and 28 per private one, so 2101 per
port for the 42 counters the poll refreshes every three seconds, and
1003 for a full ethtool -S. The SDK writes those registers only ahead
of a write command, never before a read, so this has no vendor
precedent and is not verified on silicon. The word accessor now clamps
both ends of the window, so the one counter whose computed offset comes
out negative reads the first word of the entry where it used to read a
register outside it.
Two further changes are deliberate. The PIE rule writers invalidated a
rule by committing whatever a previous transaction had left in the data
registers, and now commit the zeroed entry the function already
prepares; on RTL838x that same exit is taken when the actions do not
fit, where the entry is half built. rtl930x_packet_cntr_clear() moves
the whole row through a buffer rather than poking one data register,
keeping the read-before-clear main already has.
Of the four families only RTL930x is available here, and the series has
not been run on it either.
Compile-tested on realtek/rtl839x and realtek/rtl930x.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25062
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 20:18:58 +02009f62ca8ff14d701928b425b53d0093de80eb0df6realtek: table: read and write whole table entriesedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/table.hedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.hedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl839x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl838x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.c0768ca4c67883b6808c66c601e33d2aa0af151ff1788895713000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl931x: fix the FlexibleOctetsCRCSet1 offsets
rtldsa_931x_stat_port_table_read() takes a counter out of an entry as
field_offset - mib_offset, where field_offset is the last word of the
table. That is the SDK's own arithmetic: table_field_get() computes
datareg_num - 1 - (lsp >> 5) in hal/mac/mem.c, so mib_offset has to be
the field's lsp divided by 32.
Two entries do not satisfy it. tx_PktsFlexibleOctetsCRCSet1 carries 28
for a table 28 words wide, which lands one word below the data window,
on the table command register; since 9f62ca8ff1 the word accessor
clamps that to the first word. rx_PktsFlexibleOctetsCRCSet1 carries 27,
which is the first word, so it reports rx_UndersizeDropPkts: two
ethtool names, one counter.
The GPL SDK puts both fields in the private counter table at lsp 640
and 608 (src/hal/chipdef/mango/rtk_mango_tableField_list.c), so the
offsets are 20 and 19. With those, the private entries are the
descending run their neighbours already follow, and every offset in the
list equals the lsp/32 of a distinct field. No offset in the driver
comes out negative any more, so the note about that goes with them.
Source analysis only, against the GPL SDK. No RTL9310 was available to
read the two counters before and after.
Compile-tested on realtek/rtl931x.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25083
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 21:28:33 +02000768ca4c67883b6808c66c601e33d2aa0af151ffrealtek: dsa: rtl931x: fix the FlexibleOctetsCRCSet1 offsetsedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.c769116266bb9d67b5d0cd30c7eb018e796d6aa7e1788895713000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl931x: fix the single collisions offset
.single_collisions carries offset 35, which is word 17 of the standard
counter table, DOT1DTPPORTINDISCARDS. The counter the field names,
DOT3STATSSINGLECOLLISIONFRAMES, is at lsp 1088 in the GPL SDK field
list (src/hal/chipdef/mango/rtk_mango_tableField_list.c), so the offset
is 34 and the word 18.
A port therefore reports one counter under two names: as
dot1dTpPortInDiscards in ethtool -S, which reads offset 35 from the
same table, and as SingleCollisionFrames in the eth-mac group, which
takes .single_collisions from the counter poll.
The offset stays inside the table, so it produced a plausible number
rather than a read outside the window, and nothing in the driver
reports either case.
Source analysis only, against the GPL SDK. No RTL9310 was available to
read the counter before and after.
Compile-tested on realtek/rtl931x.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25083
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-08 21:28:33 +0200769116266bb9d67b5d0cd30c7eb018e796d6aa7erealtek: dsa: rtl931x: fix the single collisions offsetedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl838x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl839x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c8ecfbbe00290c1fdc0fea15a50972097ecff92af1788941999000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: pass priv to the packet counter ops, use dev_dbg
The per-SoC packet_cntr_read() / packet_cntr_clear() ops only had the
raw counter index to work with, so their tracing went through
pr_debug("In %s ...", __func__). Give both ops a struct
rtl838x_switch_priv *priv argument - every call site already has one -
drop the __func__ noise and describe what the call does with dev_dbg().
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25076
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 10:19:59 +02008ecfbbe00290c1fdc0fea15a50972097ecff92afrealtek: dsa: rtl83xx: pass priv to the packet counter ops, use dev_dbgedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.hedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl838x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl839x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mactarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m-nand.dtsotarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m-emmc.dtsotarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m.dts235fe894cf1ee67b2fd713fe071afd5beaca37e51788948213000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.demediatek: filogic: cmcc rax3000m: use mac-address nvmem cells
Add two mac-base nvmem cells (macaddr_factory_4, macaddr_factory_a)
and map them as per-band mac-address entries in the emmc and nand
DTS overlays.
Since the per-band entries are added as addressed band@0/band@1
child nodes, declare #address-cells = <1> and #size-cells = <0> on
the shared &wifi node in mt7981b-cmcc-rax3000m.dts.
Remove the cmcc,rax3000m special case from the ieee80211 hotplug
script, which previously read eth0. MAC address assignment is now
handled via DT/nvmem instead.
Verified the resulting MAC addresses are unchanged.
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24575
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 12:03:33 +0200235fe894cf1ee67b2fd713fe071afd5beaca37e5mediatek: filogic: cmcc rax3000m: use mac-address nvmem cellsedittarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m-nand.dtsoedittarget/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_macedittarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m.dtsedittarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m-emmc.dtso
- package/boot/uboot-mediatek/patches/437-add-cmcc_rax3000m.patchpackage/boot/uboot-mediatek/Makefile6350d57c00283693b8befd532512a6fc2f595f5f1788948214000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.deuboot-mediatek: cmcc rax3000m: add UBI variant
Add the CMCC RAX3000M(e) UBI-enabled U-Boot target for both DDR3 and DDR4 builds.
Refactor the CMCC RAX3000M(e) device trees.
The board-specific DTS variants for eMMC, NAND, and UBI now
inherit the common setup while overriding the required
flash configuration and partitions.
This keeps the common MT7981 wiring centralized and
makes each RAX3000M variant explicit and maintainable.
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24575
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 12:03:34 +02006350d57c00283693b8befd532512a6fc2f595f5fuboot-mediatek: cmcc rax3000m: add UBI varianteditpackage/boot/uboot-mediatek/patches/437-add-cmcc_rax3000m.patcheditpackage/boot/uboot-mediatek/Makefile
- target/linux/mediatek/image/filogic.mktarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m-ubi.dtsoa55d09d2917a55ab2eeb2dd5bb0866bb4cd9b5241788948214000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.demediatek: filogic: cmcc rax3000m: add all-in-UBI layout
This commit introduces OpenWrt U-Boot all-in-UBI layout support
for the CMCC RAX3000M / RAX3000Me, enabling:
- Prolonged device lifetime by allocating most of the flash
to UBI (which takes care of wear-leveling)
- Maximum available storage space for OpenWrt
OpenWrt U-Boot UBI flash instructions
-------------------------------------
A device running stock firmware should be upgraded to the
latest OpenWrt firmware
(https://firmware-selector.openwrt.org/?target=mediatek%2Ffilogic&id=cmcc_rax3000m).
Back up critical data
---------------------
LuCI Web-UI:
"System" -> "Backup / Flash Firmware" -> "Save mtdblock contents"
Save mtdblock:
factory
Make sure the file were successfully downloaded to your downloads directory.
Using the installer image
-------------------------
To simplify the installation process, this method uses a fork
of Daniel Golle's (@dangowrt) UBI Installer
https://github.com/dangowrt/owrt-ubi-installer
1. Ensure your router is running the latest OpenWrt firmware.
Upgrade it if necessary.
2. Obtain the installer image:
Build the installer from source according to your device variant
https://github.com/andros-ua/owrt-ubi-installer/tree/rax3000m-ddr3
or
https://github.com/andros-ua/owrt-ubi-installer/tree/rax3000m-ddr4
or download a prebuilt image from the
https://github.com/andros-ua/owrt-ubi-installer/releases
3. Flash the openwrt*-initramfs-recovery-installer.itb
image using sysupgrade.
4. Wait for installation:
the green status LED will blink rapidly,
indicating that the all-in-UBI installer is running.
Once the installation finishes,
the status LED will turn solid amber for 5 seconds.
5. After the device reboots, perform a final sysupgrade using the
openwrt*-squashfs-sysupgrade.itb image.
BL2 and FIP Recovery
--------------------
Use mtk_uartboot to recover corrupted BL2 or FIP via UART:
https://github.com/981213/mtk_uartboot
OpenWrt U-Boot layout
----------------------------------------
| dev: size erasesize name |
| mtd4: 00100000 00020000 "bl2" |
| mtd3: 00080000 00020000 "u-boot-env" |
| mtd2: 00200000 00020000 "factory" |
| mtd1: 00200000 00020000 "fip" |
| mtd0: 07200000 00020000 "ubi" |
----------------------------------------
OpenWrt U-Boot UBI layout
----------------------------------
| dev: size erasesize name |
| mtd1: 00100000 00020000 "bl2" |
| mtd0: 07f00000 00020000 "ubi" |
----------------------------------
Update MAC table after inspecting the factory partition:
----------------------------------------------------------------
| Interface | MAC | Source | |
|--------------|-------------------|---------------|-----------|
| WAN (label) | 54:4d:d4:xx:xx:xx | factory, 0x24 | label |
| LAN | 54:4d:d4:xx:xx:xx | factory, 0x2a | label + 3 |
| WLAN 2.4 GHz | 54:4d:d4:xx:xx:xx | factory, 0x4 | label + 1 |
| WLAN 5 GHz | 54:4d:d4:xx:xx:xx | factory, 0xa | label + 2 |
----------------------------------------------------------------
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24575
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 12:03:34 +0200a55d09d2917a55ab2eeb2dd5bb0866bb4cd9b524mediatek: filogic: cmcc rax3000m: add all-in-UBI layoutaddtarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m-ubi.dtsoedittarget/linux/mediatek/image/filogic.mk
- target/linux/mediatek/filogic/base-files/etc/board.d/05_compat-versiontarget/linux/mediatek/image/filogic.mktarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m.dtstarget/linux/mediatek/filogic/base-files/etc/board.d/02_network05e95a3bb5cac1d2a3ec4eb55fc95070c72de0331788948214000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.demediatek: filogic: cmcc rax3000m: label WAN port
The device has a label on the WAN port; add a matching DT openwrt,netdev-name.
Add openwrt,netdev-name = "wan" to gmac1 (mac@1) in mt7981b-cmcc-rax3000m.dts
to identify the WAN port. Move the cmcc,rax3000m entry to the
appropriate case block in
target/linux/mediatek/filogic/base-files/etc/board.d/02_network
so mediatek_setup_interfaces handles the device correctly.
Bump the compat version so sysupgrade shows the warning message.
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24575
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 12:03:34 +020005e95a3bb5cac1d2a3ec4eb55fc95070c72de033mediatek: filogic: cmcc rax3000m: label WAN portedittarget/linux/mediatek/filogic/base-files/etc/board.d/05_compat-versionedittarget/linux/mediatek/image/filogic.mkedittarget/linux/mediatek/dts/mt7981b-cmcc-rax3000m.dtsedittarget/linux/mediatek/filogic/base-files/etc/board.d/02_network
- target/linux/apm821xx/nand/target.mktarget/linux/apm821xx/image/nand.mk7a1684be88ad476d690e156716394795be1764b81788948333000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.deapm821xx: add ubifs support
ubifs support can be added to have a single R/W volume for the device.
Currently only the MX60 enables it as the others are missing runtime
information to enable usage.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25000
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 12:05:33 +02007a1684be88ad476d690e156716394795be1764b8apm821xx: add ubifs supportedittarget/linux/apm821xx/nand/target.mkedittarget/linux/apm821xx/image/nand.mk
- target/linux/realtek/base-files/etc/init.d/hwmon_fancontroltarget/linux/realtek/base-files/etc/uci-defaults/04_dlinkfantarget/linux/realtek/base-files/sbin/fan_ctrl.shtarget/linux/realtek/base-files/etc/uci-defaults/04_dlinkfan_migrationd3290efad9a97f1b49dabc5244ca0b6164ef0be01788948682000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.derealtek: use autonomous LM63 fan control on DGS-1210-28P/MP
Previously, fan control on D-Link DGS-1210-28P/MP switches was handled
by a user-space script (`fan_ctrl.sh`) triggered via cron every 5
minutes due to missing kernel sysfs writable attributes for PWM
frequency and hysteresis.
The `fan_ctrl.sh` contained a string-truncation comparison logic bug
(temp1_input was truncated while PSU_THRESH was not) that kept the fan
locked at a static 156 PWM (61%) rate regardless of temperature.
Also, since hwmon0 (cpu_thermal) appeared, it changed the order of hwmon
devices and broke fan_ctrl.sh PWM control, keeping it always stopped.
With commit 89ef8aaf3e ("kernel: backport lm63 enhancements"),
`pwm1_freq` and `pwm1_auto_point_temp_hyst` are now writable, enabling
full autonomous LUT hardware fan management on the LM63 chip.
Transition to autonomous hardware fan control:
- Configure LM63 Look-up Table (LUT) via `/etc/init.d/hwmon_fancontrol`
using the OEM register settings:
* PWM Frequency: ~7826 Hz (PFR divisor 23)
* Point 1: > 0°C -> PWM 28/46, 155/255 (~60.8% duty cycle)
* Point 2: > 51°C -> PWM 46/46, 255/255 (100% duty cycle)
* Points 3-8: > 127°C -> PWM 255/255 (chip defaults for unused points)
* Hysteresis: 3°C (3000 mC)
- Add `04_dlinkfan_migration` migration script to purge `fan_ctrl.sh` from
crontab during sysupgrade.
The LM63 PWM resolution depends on the PFR divisor setting (2 * PFR).
With PFR set to 23 (matching OEM ~7826 Hz), full scale is 46 (0x2e). The
sysfs interface maps 0-255 to 0-46, meaning the OEM defaults 28 (0x1c)
and 46 (0x2e) translate to sysfs values 155 (~60.8% duty cycle) and 255
(100% duty cycle). Those values match the old fan_ctrl.sh temperature range
and duty cycle.
Fixes: ab3f92e86481 ("realtek: add fan controller support to D-Link DGS-1210-28MP")
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24869
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 12:11:22 +0200d3290efad9a97f1b49dabc5244ca0b6164ef0be0realtek: use autonomous LM63 fan control on DGS-1210-28P/MPaddtarget/linux/realtek/base-files/etc/uci-defaults/04_dlinkfan_migrationdeletetarget/linux/realtek/base-files/etc/uci-defaults/04_dlinkfanedittarget/linux/realtek/base-files/etc/init.d/hwmon_fancontroldeletetarget/linux/realtek/base-files/sbin/fan_ctrl.sh
- target/linux/mediatek/filogic/base-files/lib/upgrade/platform.shpackage/boot/uboot-tools/uboot-envtools/files/mediatek_filogicdcb5ede455e89bb682453133fc32a709e09343ec1788954034000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.demediatek: fix U-Boot env geometry for JioRouter AX6000 JIDU6101
Correct the U-Boot env geometry from "0x80000" "1" to "0x1f000" "5".
The correct LEB size for 128k PEB / 2k page is 0x1f000, and the 0x80000 volume spans 5 LEBs.
This also hardens jiorouter_initial_setup by adding proper error handling
and dynamic UBI device/volume lookups, and generates /etc/fw_env.config to be consistent.
Signed-off-by: Sheikh Faisal <sheikhfaisal713@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23510
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 13:40:34 +0200dcb5ede455e89bb682453133fc32a709e09343ecmediatek: fix U-Boot env geometry for JioRouter AX6000 JIDU6101edittarget/linux/mediatek/filogic/base-files/lib/upgrade/platform.sheditpackage/boot/uboot-tools/uboot-envtools/files/mediatek_filogic
- target/linux/mediatek/image/filogic.mk42eab6a9d30485e84f9a487172b907e75322ac321788954034000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.demediatek: filogic: drop kmod-mt7916-firmware from JIDU6101
This device uses MT7976 radios and does not use the MT7916 blob.
Drop the unnecessary firmware package.
Signed-off-by: Sheikh Faisal <sheikhfaisal713@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23510
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 13:40:34 +020042eab6a9d30485e84f9a487172b907e75322ac32mediatek: filogic: drop kmod-mt7916-firmware from JIDU6101edittarget/linux/mediatek/image/filogic.mk
- target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_macpackage/boot/uboot-tools/uboot-envtools/files/mediatek_filogictarget/linux/mediatek/dts/mt7986a-jiorouter-ax6000-jidu6j01.dtstarget/linux/mediatek/image/filogic.mktarget/linux/mediatek/filogic/base-files/lib/upgrade/platform.shtarget/linux/mediatek/filogic/base-files/etc/board.d/02_network552e617bd0ae18fce68fa1b9add4c4cc50da7d871788954034000https://taiha.net/jenkins/user/jonasjonasjonas@jonasjelonek.demediatek: add support for JioRouter AX6000 JIDU6J01
| Component | Details |
|------------------|------------------------------------------------|
| **SoC** | MediaTek MT7986A (4× ARM Cortex-A53 @ 2.0 GHz) |
| **RAM** | 512 MB |
| **Flash** | 256 MB NAND |
| **Ethernet** | 5× 10/100/1000 Mbps (1 WAN + 4 LAN) |
| **WLAN 2.4 GHz** | MediaTek MT7976GN — 802.11b/g/n/ax, 4×4 MIMO |
| **WLAN 5 GHz** | MediaTek MT7976AN — 802.11n/ac/ax, 4×4 MIMO |
| **LEDs** | 1× RGB LED (GPIO-controlled) |
| **Button** | 1× Reset |
| **USB** | Yes |
**MAC Addresses:**
| Interface | Source |
|------------|-------------------------------------------------|
| WAN/Label | MFG MTD partition (variant-specific fallback) |
| LAN | WAN + 1 |
| 2.4 GHz | WAN + 2 |
| 5 GHz | WAN + 3 |
Supported variants and MAC source:
- JIDU6J01,JIDU6201: binary at offset 0x00
- JIDU6401: binary at offset 0x20
- JIDU6601: ASCII text at offset 0x1d0
- JIDU6701: ASCII mac= key
---
**1. Extracting U-Boot Credentials**
The U-Boot username and password are stored in the `MFG` partition. To retrieve them:
- With root access on stock OS: Read directly from the MFG partition.
- Without root access: Dump the NAND flash first, then extract the credentials from the dump.
**2. Prepare TFTP server**
- Set a static IP on the ethernet interface of your computer
(e.g. default: ip `192.168.1.2`, gateway `192.168.1.1`).
- Download the initramfs image and host it with the TFTP server.
**3. Interrupt boot**
Attach UART and power on the router. When the boot menu appears, select **Failsafe Mode**,
then press `Ctrl-C` to interrupt and enter the credentials extracted from `MFG` partition.
**4. Load and run initramfs image**
```sh
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.2
tftpboot 0x46000000 openwrt-mediatek-filogic-jiorouter_ax6000-jidu6j01-initramfs-kernel.bin
fdt addr $(fdtcontroladdr)
fdt rm /signature
bootm
```
**5. Flash sysupgrade image**
Place the sysupgrade image in `/tmp`, then run:
```sh
sysupgrade /tmp/openwrt-mediatek-filogic-jiorouter_ax6000-jidu6j01-squashfs-sysupgrade.bin
```
Alternatively, use the sysupgrade option in LuCI.
Signed-off-by: Sheikh Faisal <sheikhfaisal713@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23510
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-09 13:40:34 +0200552e617bd0ae18fce68fa1b9add4c4cc50da7d87mediatek: add support for JioRouter AX6000 JIDU6J01editpackage/boot/uboot-tools/uboot-envtools/files/mediatek_filogicedittarget/linux/mediatek/filogic/base-files/lib/upgrade/platform.shedittarget/linux/mediatek/image/filogic.mkaddtarget/linux/mediatek/dts/mt7986a-jiorouter-ax6000-jidu6j01.dtsedittarget/linux/mediatek/filogic/base-files/etc/board.d/02_networkedittarget/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
- package/utils/adb/patches/010-mbedtls.patchpackage/utils/adb/Makefile5f62b79d1cf7ee0c903aa98995828a49c26dd1d41788968010000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comadb: fix RSA authentication with mbedTLS
ADB authentication signs the 20-byte challenge directly as a SHA-1
digest. The mbedTLS port hashes the challenge before signing it,
causing adbd to reject every signature and request user approval
after each server restart.
Pass the challenge directly to mbedtls_pk_sign(), matching the former
RSA_sign() behavior.
Signed-off-by: Vladimir Zadirei <v.zadirei@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24946
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 17:33:30 +02005f62b79d1cf7ee0c903aa98995828a49c26dd1d4adb: fix RSA authentication with mbedTLSeditpackage/utils/adb/patches/010-mbedtls.patcheditpackage/utils/adb/Makefile
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/dsa.ce4e60164ba1d0544b84c0c79c08dcca8dfc8c05b1788973759000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: fix mirror teardown on RTL839x/931x
rtldsa_port_mirror_del() clears the port's bit with the family accessor
priv->r->mask_port_reg_be(), then decides whether the mirror group has
become empty with a plain sw_r32(). On RTL839x and RTL931x the source
and destination port matrices are 64 bit wide: their registers are
spaced group * 8, and mask_port_reg_be() writes bits 63:32 at reg and
bits 31:0 at reg + 4. A single sw_r32() therefore reads only the word
holding ports 32 and above, so the bits of ports 0 to 31 are invisible
to the test.
Mirrors that share a monitor port share a group. Remove one of them
while every remaining source port is below 32, and the test reads zero
and takes the teardown branch: MIR_CTRL is overwritten while the
matrices still carry the surviving ports. Mirroring stops for a rule
that tc still lists, and the group is marked free although it is not.
Read the matrices with priv->r->get_port_reg_be(), which is what the
twin rtldsa_port_mirror_add() already uses on the same matrix.
The register widths come from the Realtek GPL SDK register lists:
src/hal/chipdef/cypress/rtk_cypress_reg_list.c gives MIR_SPM_CTRL at
0x2510 with a bit offset of 64, rtk_mango_reg_list.c gives 0xAF10 with
64 as well, while rtk_longan_reg_list.c gives 0xA2B0 with 32.
RTL838x and RTL930x are unaffected: .get_port_reg_be is
rtl838x_get_port_reg() there, whose body is return ((u64)sw_r32(reg)),
so the new expression performs the same read, and their matrices are
single 32 bit registers anyway.
Compile-tested on realtek/rtl839x, realtek/rtl931x and realtek/rtl930x.
Not tested on hardware: no RTL839x or RTL931x board is available here.
Reported in https://github.com/openwrt/openwrt/issues/25087, which
carries a test procedure for someone who has one.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25088
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 19:09:19 +0200e4e60164ba1d0544b84c0c79c08dcca8dfc8c05brealtek: dsa: fix mirror teardown on RTL839x/931xedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/dsa.c
- target/linux/realtek/patches-6.18/821-add-realtek-pcie-phy-driver.patchtarget/linux/realtek/files-6.18/drivers/phy/realtek/phy-rtk-pcie.cbb00e9f0974f483dfb4a88e6c50331b9aa783c781788977794000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: phy: add support for rtl9607c pcie phy
Add the support for PCIE PHY found in Realtek SoCs. For now, only RTL9607C
revisions A and B are supported but other chips like RTL8198C could be added
as well if they are similar enough.
Most of the code was copied over from phy-rtk-usb3 driver as they both have
striking similarities in phy calibration with some added changes that address
flaws of phy-rtk-usb3. The other bits have come from pci driver from GPL source
that seem most relevant to PHY side compared to PCIE controller side.
This PHY driver is gonna be used by the Realtek PCIE controller in the next
patch of this series.
Co-developed-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/24983
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 20:16:34 +0200bb00e9f0974f483dfb4a88e6c50331b9aa783c78realtek: phy: add support for rtl9607c pcie phyaddtarget/linux/realtek/patches-6.18/821-add-realtek-pcie-phy-driver.patchaddtarget/linux/realtek/files-6.18/drivers/phy/realtek/phy-rtk-pcie.c
- target/linux/realtek/files-6.18/arch/mips/include/asm/mach-rtl-otto/spaces.htarget/linux/realtek/files-6.18/drivers/pci/controller/pcie-realtek.ctarget/linux/realtek/patches-6.18/822-add-realtek-pcie-controller-driver.patch779c6d37691a3b8f5b1496b2b5c04f7e3821aeb71788977794000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: pci: add rtl9607c pcie controller support
This patch adds support for PCIE controller found on Realtek SoCs
like RTL9607C/RTL8198D. At this moment, only RTL9607C/RTL8198D are
supported but the RTL8198C could be added as they seem to be quite
similar.
PCIE controller on RTL9607C / RTL8198D SoCs have 2 PCIE ports, one
for 2.4G wifi chipset and the other for 5G wifi chipset.
The spaces.h header is also added with the size of 0x10000 for each
PCIe port so that both IO resources could have space to be assigned.
The initial version of the pcie controller driver was written by
Naseef, which later on was split into seperate PHY and controller
parts and made more upstream friendly.
Co-developed-by: Ahmed Naseef <naseefkm@gmail.com>
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Co-developed-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/24983
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 20:16:34 +0200779c6d37691a3b8f5b1496b2b5c04f7e3821aeb7realtek: pci: add rtl9607c pcie controller supportaddtarget/linux/realtek/files-6.18/arch/mips/include/asm/mach-rtl-otto/spaces.haddtarget/linux/realtek/files-6.18/drivers/pci/controller/pcie-realtek.caddtarget/linux/realtek/patches-6.18/822-add-realtek-pcie-controller-driver.patch
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/dsa.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c85d9dbad33a0420c8404eb4f26c1b137e4425fcb1788980265000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: give the tc flow hashtable a real lifecycle
The rhashtable that stores offloaded tc flows was initialised lazily from
a "first_time" static in rtl83xx_setup_tc() and never torn down. Add
rtldsa_tc_init() / rtldsa_tc_cleanup() helpers, track initialisation in
the switch private data, set the table up in rtldsa_93xx_setup() and free
it (RCU-safely) from rtl83xx_sw_remove() and the probe error path.
This changes two things for the existing (rtl930x only) user:
- "first_time" was a function-scope static shared by every switch
instance, so on a multi-switch system only the first one to take a
TC_SETUP_BLOCK ever got a tc_ht. Each switch now gets its own at
probe.
- a table init failure is propagated out of probe instead of only
being logged while setup continues.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25094
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 20:57:45 +020085d9dbad33a0420c8404eb4f26c1b137e4425fcbrealtek: dsa: rtl83xx: give the tc flow hashtable a real lifecycleedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/common.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/dsa.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.hedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c0c4e7603be4d1a62ea5d9203342db0fc97e324471788980266000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: serialize the tc flower add/del/stats callbacks
The tc cls_flower add / del / stats callbacks reach per-switch state -
the flow hashtable, the PIE rule IDs and the LOG counters - that has no
serialization of its own. Every caller currently runs under rtnl
(dsa_user_setup_tc_block() does not set unlocked_driver_cb, so
tcf_block_bind() bumps block->lockeddevcnt and tc_setup_cb_*() takes
rtnl), so this is not a bug that can be hit today, but nothing in the
driver documents or enforces that. It also leaves
rtldsa_configure_flower() publishing a flow into tc_ht before
pie_rule_add() has assigned its rule ID, where an unlocked delete racing
the add would call pie_rule_rm() with rule.id still 0 and tear down an
unrelated PIE rule.
Add a per-switch tc_flow_lock mutex, set up and torn down alongside the
flow hashtable, and hold it across the whole body of
rtldsa_configure_flower(), rtldsa_delete_flower() and
rtldsa_stats_flower(). This makes the serialization explicit and local
rather than an unstated reliance on the caller. tc_flow_lock is the
outermost tc lock - reg_mutex and pie_mutex are always taken under it,
never the other way round.
The three callbacks are reworked here, so also rename them from the
rtl83xx_ to the rtldsa_ prefix to match the surrounding tc flower code.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25094
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 20:57:46 +02000c4e7603be4d1a62ea5d9203342db0fc97e32447realtek: dsa: rtl83xx: serialize the tc flower add/del/stats callbacksedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.h
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.cb7838d861f869631e41c8b8c7c6e22a43fdc75ff1788980266000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: read the tc flow counter outside the RCU lock
rtldsa_stats_flower() looked the flow up without rcu_read_lock() at all
and then called packet_cntr_read(), which sleeps.
Do the rhashtable lookup in a short RCU section and read the hardware
counter with reg_mutex held once RCU is dropped; tc_flow_lock (held for
the whole callback) keeps the flow alive across the read. Use u32 for the
packet counters, return -ENOENT when the flow is gone, switch the debug
print to dev_dbg(), and report the real packet count instead of a
synthetic byte estimate.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25094
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 20:57:46 +0200b7838d861f869631e41c8b8c7c6e22a43fdc75ffrealtek: dsa: rtl83xx: read the tc flow counter outside the RCU lockedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c1d398b5cc3c508280e6c1744c84962557c07e74c1788980266000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: release a flow's LOG counter when it is destroyed
rtldsa_configure_flower() allocates a LOG-table packet counter with
rtldsa_packet_cntr_alloc(), but the flow teardown paths
(rtldsa_tc_flow_free() and rtldsa_delete_flower()) never called
rtldsa_packet_cntr_free(), so every removed offloaded flow leaked its
counter slot until the bitmap filled up.
Add rtldsa_packet_cntr_release(): zero the hardware counter and hand the
slot back, in that order, so a slot is never returned to the allocator
while the hardware entry still holds the previous flow's count. Call it
from both teardown paths and from the configure error unwind (which
already freed the slot but left the hardware counter dirty). The helper
is a no-op while no counter is assigned (rule.packet_cntr starts at -1).
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25094
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 20:57:46 +02001d398b5cc3c508280e6c1744c84962557c07e74crealtek: dsa: rtl83xx: release a flow's LOG counter when it is destroyededittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.ca92bb742978d9531cd5b9ecbd68ad28505b18ef61788980266000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: rtl83xx: hold tc_flow_lock in rtldsa_tc_cleanup()
The add, delete and stats cls_flower callbacks all run under
tc_flow_lock, but rtldsa_tc_cleanup() walked and destroyed tc_ht
without it and then destroyed the mutex. A callback that raced teardown
could therefore walk a flow that rtldsa_tc_flow_free() is freeing, or
call pie_rule_rm() on a rule this path already removed.
Take tc_flow_lock around rhashtable_free_and_destroy() and clear
tc_initialized under it, so any in-flight callback completes before the
table is torn down. Drop the lock before rcu_barrier() / mutex_destroy().
A callback that was already blocked on tc_flow_lock when teardown ran
would still wake into a freed tc_ht, so the three callbacks re-check
tc_initialized right after they take the lock and return -ENODEV when
it is clear.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25094
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-09-09 20:57:46 +0200a92bb742978d9531cd5b9ecbd68ad28505b18ef6realtek: dsa: rtl83xx: hold tc_flow_lock in rtldsa_tc_cleanup()edittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/tc.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c51e2f22a91b98c3ff57fa931d7fb69cde485c0731788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: make the bridge VLAN translation rules match
An ingress VLAN translation rule selects the frames it applies to with two
frame-format fields, and both are match bitmaps: a zero matches no frame at
all. ppe_xlt_rule_set() only ever wrote the C-tag side, so every rule the
bridge VLAN path installs has been inert since the driver was added - no
bridge VLAN has ever been classified into its own VSI in hardware. Readback
on IPQ8074 with a VLAN-filtering bridge shows the S-tag format zero on the
rule.
Setting it is half the fix. Live, the rule then applies its action, and the
action deletes the C-tag: the frame reaches the CPU untagged, the software
bridge reads it as the port's PVID rather than the VLAN it arrived on, and
it never reaches that VLAN's upper device. So the rule classifies and
nothing more - the VSI carries the domain from there, and which ports
egress the VLAN untagged is already EG_VSI_TAG's decision, programmed by
ppe_eg_vsi_tag_port_set().
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44) with br-lan over lan1-3,
VID 20 tagged on one port and a tagged client on it. One register write
apart: with the tag edit the VLAN's upper device receives nothing, without
it the client passes traffic over the VLAN.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +020051e2f22a91b98c3ff57fa931d7fb69cde485c073qualcommax: qca_ppe: make the bridge VLAN translation rules matchedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.cedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.h
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.ca8402a5218bee8b49250d1b5b0f0783bf84ee16c1788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: keep a bridge VLAN across a filtering toggle
A translation rule that is live has to stop classifying while its bridge
does not filter, and start again when it does. The driver opted into the
legacy DSA behaviour instead, where a port under a bridge with
vlan_filtering=0 is offered no VLAN configuration at all; the bridge VLANs
then reach the hardware neither while filtering is off nor when it comes
back on, which net/dsa/user.c describes as broken and discouraged.
Take the default, record the bridge VLANs either way, and mask the port out
of the rules and the VSI member set while it does not filter. A port that
starts filtering reprograms every VLAN entry naming it from the state the
driver kept.
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44) with br-lan over lan1-3
and VID 20 tagged on one port. While filtering is off the VLAN's rule reads
back valid with an empty port bitmap and its VSI with an empty member mask;
with filtering on the same rule names the three ports and the CPU port.
Three off-and-on cycles leave the translation, action and VSI tables
byte-identical to the state before the first cycle, and the port forwards
after each one.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +0200a8402a5218bee8b49250d1b5b0f0783bf84ee16cqualcommax: qca_ppe: keep a bridge VLAN across a filtering toggleedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.hedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c8826898af11eb883d0d44a64b33c0b98f5010fa61788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: release a port's old pvid rule when its pvid changes
The bridge announces a new pvid as an add of that vid alone, so the entry
holding the port's untagged rule is never told it lost the port. It keeps
the port in its pvid set, and two translation rules then claim the same
port's untagged frames.
Drop the port from the entry its previous pvid names before the new entry
takes it.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02008826898af11eb883d0d44a64b33c0b98f5010fa6qualcommax: qca_ppe: release a port's old pvid rule when its pvid changesedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c22eb4678992cd10b4173e166dec2dd69ef55fa1e1788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: program a VLAN's translation action before its rule
A VLAN's translation rule is made live before the action that names the VSI
it classifies into. The action of a freshly allocated index is all zeroes,
so between the two writes a tagged frame matching the new rule takes no VSI
command and is bridged in the port's own domain rather than the VLAN's. The
teardown path already clears the rule before the action; the setup path now
mirrors it.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +020022eb4678992cd10b4173e166dec2dd69ef55fa1equalcommax: qca_ppe: program a VLAN's translation action before its ruleedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c1b03fac5ccab921b9b9092c3fc0c54bfb91826351788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: name the translation-miss command for what it does
PPE_XLT_MISS_FWD_DROP is the value PPE_VLAN_XLT_MISS_FWD takes on a port
that filters, and the name says the hardware drops a frame whose VLAN no
translation rule matches. It does not: with filtering enabled on lan1-lan3
and no rule matching their VLAN, an ssh session over lan1 and a ping across
lan3 both survive, so those frames are not discarded.
Three is redirect-to-CPU in the forwarding-command encoding this hardware
uses, which the kernel's own ppe driver spells out:
drivers/net/ethernet/qualcomm/ppe/ppe_config.h:
PPE_ACTION_FORWARD = 0,
PPE_ACTION_DROP = 1,
PPE_ACTION_COPY_TO_CPU = 2,
PPE_ACTION_REDIRECT_TO_CPU = 3,
and which this driver already carries in PPE_APP_CTRL_REDIRECT_CPU. Name
this one to match.
The value and the behaviour are unchanged; only the name stops claiming the
opposite of what the port does.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02001b03fac5ccab921b9b9092c3fc0c54bfb9182635qualcommax: qca_ppe: name the translation-miss command for what it doesedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.hedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.ctarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c585137af02dc210e6088653c002ac6e97c437a271788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: key the FDB and MDB on the VSI, not the vid
The PPE keys an L2 entry on the VSI the frame carries, not on the vid Linux
passed.
ppe_fdb_encode() put DSA's vid into the entry's VSI field, and so did the
multicast encoder and the lookup key. A VLAN-unaware bridge passes vid 0,
so every entry the driver wrote landed in VSI 0 - the standalone domain
reserved at setup - while the bridge forwards on a VSI allocated from 1 up.
The entries could never match. Hardware learning hides most of it: the PPE
learns any address that transmits on a physical port into the frame's own
VSI, so wired unicast switches correctly and nothing looks wrong. What is
left is exactly the set the hardware cannot learn, which is the only set
DSA offloads - addresses behind the CPU port. On this board that is every
Wi-Fi station, installed by assisted_learning_on_cpu_port, plus the
router's own MACs. Each sat in VSI 0 and was never hit, so wired-to-Wi-Fi
unicast stayed unknown and flooded the bridge. Multicast has no learning
fallback at all, so the MDB offload was a silent no-op.
Resolve the VSI where the bridge is known, at the DSA op, and pass a VSI
down. A vid naming one of the driver's bridge VLANs gives that VLAN's VSI;
any other vid, including the 0 a VLAN-unaware bridge passes, gives the
bridge's own VSI, which is the domain those frames are forwarded in. An
entry that names no bridge resolves to nothing and is refused rather than
written into VSI 0. The dump had the same confusion in reverse, reporting
the VSI as a vid, which printed a phantom "vlan 1" against every
hardware-learned entry. It takes the inverse mapping here, because it is
the same defect on the way out. Renaming the helpers' parameter is what
stops it coming back.
The lookup walks the bridge and VLAN state that the switchdev ops mutate,
and DSA runs the FDB and MDB ops from an ordered workqueue that holds no
rtnl, so both sides take a mutex. An MDB update reads an entry's port map
and writes it back, which the same mutex makes atomic.
Tested on an AX3600 (IPQ8074, 6.18) with a VLAN-unaware br-lan over lan1-3
and two APs. A full walk of the 2048 FDB entries showed both halves of the
defect at once: 00:00:5e:00:53:01 at VSI 1 from the bridge's own vid 1
entry and again at VSI 0 from the vid 0 one, with station 00:00:5e:00:53:02
towards the CPU port at VSI 0. After the change no entry is left in VSI 0,
the duplicate pair is one entry, and every station address is at VSI 1.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +0200585137af02dc210e6088653c002ac6e97c437a27qualcommax: qca_ppe: key the FDB and MDB on the VSI, not the videdittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.cedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.hedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_vlan.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.cc9278473d06ab8543b6d502dd8eb9774fb8fd1831788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: let the FDB dump say it ran out of room
qca_ppe_port_fdb_dump() walks all 2048 entries and hands each match to the
callback, but it treats a failing callback as a reason to stop and then
returns success. The failure that matters is -EMSGSIZE, which is how the
callback says the netlink skb is full and the dump should resume from here.
Swallowing it tells rtnl_fdb_dump() the port finished, so it discards the
cursor and moves to the next port, and `bridge fdb show` silently reports
fewer entries than the switch holds. A port busy enough to fill an skb is
exactly the one whose table someone wants to read.
Return what the callback returned. The mutex is released by its guard
either way.
This is not a defect of the offload work in this series - the dump predates
it - so it stands on its own and applies without the rest.
Not reproduced here: filling a netlink skb needs far more entries than this
bench puts in the table, so what is shown is the contract, from
rtnl_fdb_dump()'s handling of the return value.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +0200c9278473d06ab8543b6d502dd8eb9774fb8fd183qualcommax: qca_ppe: let the FDB dump say it ran out of roomedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c6831f7b9ef5b55b2932e7d320988097b2ccdd0541788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: answer an FDB lookup only with a port map
ppe_fdb_lookup() reports any valid entry as a port map, and its caller is
the multicast path. A unicast entry carries a port number in the same
field, so a group whose slot holds one is programmed with a member set it
was never given - a multicast stream then egresses a port that never
joined. The sibling reader, ppe_fdb_read_entry(), already discriminates on
the destination type.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02006831f7b9ef5b55b2932e7d320988097b2ccdd054qualcommax: qca_ppe: answer an FDB lookup only with a port mapedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c0f9baab7f64ee23bc5688b67dba3fd0d28aa23501788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: finish an FDB operation before reading its result
The FDB operation registers report the id of the command they last
finished, and the driver waited on ids it had not issued. Four of the five
operations issued no id at all and waited for id zero, which is what the
result register reads back when it has posted nothing; the fifth, the entry
read, issued an id taken from the entry index modulo fifteen, so every
fifteenth index waited for zero too. The wait therefore returned on the
first read, before the engine had run, and the result data registers were
read while they still held whatever the previous operation left.
A multicast group added this way could not be found again: the lookup its
delete makes read all-zero data, reported the entry as absent, and the
switchdev core logged a failed delete while the hardware entry stayed
programmed - a group kept receiving on a port after its last member left.
Each operation now takes an id of its own, from one upward so that a
register which has posted nothing never answers for it, and each of the two
result registers counts on its own so an id is never the one its register
already holds. The result data is read once the register reports that id.
Measured on an ipq807x AX3600: a group added on two switch ports is
reported offloaded on both, each member deletes with no error and no
switchdev complaint, and a bridge FDB dump reads back the addresses learnt
on the three user ports.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02000f9baab7f64ee23bc5688b67dba3fd0d28aa2350qualcommax: qca_ppe: finish an FDB operation before reading its resultedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.hedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c426681cfa40f8f2779d172dbb5b12f4899d2e2a31788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: latch the port VSI binding
This PPE takes the write to a table entry's last word as the commit, so an
entry edited a word at a time is staged and never taken.
ppe_port_vsi_set() rewrote only word 1 of L3_VP_PORT_TBL, so a runtime
bridge join never bound the port to its VSI in hardware and the entry kept
whatever the previous binding left in it. Read-modify-write the whole
entry, ascending.
ppe_vsi_init() was this same dance done once at probe - its comment even
names the rule - and the DSA setup path re-binds every port through the
fixed setter before traffic flows, so it goes.
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44): taking a user port out
of the bridge and putting it back leaves L3_VP_PORT_TBL word 1 reading
0x600 and 0x000 in turn, over two cycles - the valid bit and VSI 1, whose
member mask names the CPU port and the three bridged user ports.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +0200426681cfa40f8f2779d172dbb5b12f4899d2e2a3qualcommax: qca_ppe: latch the port VSI bindingedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.ccf23d39714907ceab452c55a416009263ead61061788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: commit the port MTU write instead of staging it
The per-port size check lives in MRU_MTU_CTRL_TBL, an entry that latches on
the write to its second word. Setup gets there by accident: it writes the
sizes into word 0 and the counter enables reach word 1 later in probe, so
the entry commits. port_change_mtu edited word 0 and stopped, which leaves
the write staged, so every mtu the kernel handed down after probe was lost
and the port kept the size probe had given it.
Both callers now go through one helper that reads word 1, writes the sizes
and writes word 1 back unchanged; it carries the counter enables and the
source profile, which this path knows nothing about.
Beside each size field sits a two-bit command deciding what happens to a
frame that fails the check, and the driver left all three alone, so the
sizes were compared against and then ignored. Set them the way mainline's
ppe driver sets the same fields: a frame over the receive size goes to the
CPU, which is where an oversized routed packet has to reach for the icmp
that tells the sender to send less, and a frame over the transmit size is
dropped rather than sent back to a CPU that would only offer it to the same
port again.
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44): setting a user port's
mtu to 1400 makes its entry read back 0x458ec58e - both sizes at 1422, the
receive command redirect-to-CPU and the transmit command drop - and
0x45f2c5f2 again at 1500, over three cycles, with word 1 holding the
counter enables throughout and only the port whose mtu changed moving.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +0200cf23d39714907ceab452c55a416009263ead6106qualcommax: qca_ppe: commit the port MTU write instead of staging itedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.hedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_scheduler.c2c4a0328af06a6ffa557dcb1a9fe9fde1f0717441788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: set the QoS precedence per generation
Which classifier decides a packet's internal priority is a per-port field.
ppe_qos_init() wrote it at PPE_PRX_BASE + 0x3000 + port * 0x10 + 4, in the
packet-receive block. That offset, stride and word are the second word of a
port's MRU/MTU entry at the stride ppe_data gives IPQ6018; the base is not
the one PPE_MRU_MTU_CTRL() uses. IPQ8074's entry is eight bytes, so neither
the address nor the field positions apply to it.
Select both from the SoC through one lookup that names the register and
every field: IPQ8074 gets PPE_PORT_QOS_CTRL, and IPQ6018 keeps the
positions the driver already carried, on the MRU/MTU entry they address.
Anything else that reaches these fields goes through the same lookup rather
than open-code one generation's layout. The order asked for is unchanged -
flow above preheader, then ACL, DSCP and PCP - and nothing gives the flow
source an opinion, so the ranking below it decides.
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44): PPE_PORT_QOS_CTRL reads
back 0x00014608 on every port, and forwarding and dmesg are unchanged. The
IPQ6018 arm is not runtime tested - there is no IPQ6018 on the bench.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02002c4a0328af06a6ffa557dcb1a9fe9fde1f071744qualcommax: qca_ppe: set the QoS precedence per generationedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.hedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_scheduler.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.h8990769d1f17367947b34abb3d650fd4ec1ada731788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: fix the multicast queue resume offset field
A multicast queue's green resume offset is an 11-bit field at bit 71 of the
entry, which is bits 17:7 of its third word, not 17:11. Written four bits
too high, the 36 the driver asks for reaches the hardware as 576 - a resume
threshold below zero on a queue whose ceiling is 400, so a multicast queue
that once filled has to drain much further than intended before it accepts
again.
Readback on IPQ8074 confirms it: the word reads 0x00012000 on every
multicast queue. Upstream's own driver for the later part has the span
right (PPE_AC_MULTICAST_QUEUE_CFG_W2_RESUME, GENMASK(17, 7)).
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44): the word reads
0x00001200, multicast forwarding and an IPTV stream are undisturbed, and
dmesg is clean.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02008990769d1f17367947b34abb3d650fd4ec1ada73qualcommax: qca_ppe: fix the multicast queue resume offset fieldedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.h
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c00e31226cd78828080aea53addb208fc7e87f7471788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: enable TX pause on an XGMAC port
ppe_xgmac_link_up() masked PPE_XGMAC_TX_FLOW_ENABLE (bit 1) but wrote
PPE_XGMAC_RX_FLOW_ENABLE (bit 0) as the value, so val & mask was always
zero and TX pause never enabled on an XGMAC port regardless of what phylink
negotiated. The receive side beside it is correct and is what makes the
pair the evidence.
Only ports muxed to their XGMAC are affected - the 10G AQR ports on other
boards. Found by inspection; there is no XGMAC port on the bench to run it
on.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +020000e31226cd78828080aea53addb208fc7e87f747qualcommax: qca_ppe: enable TX pause on an XGMAC portedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.cc5adfc683037f65b6189e6cf7d2608349860a85f1788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: select port 4's PCS for every interface
The port 4 arm of the PCS mux assigns its value only for QSGMII and PSGMII
and writes the register on every interface, so an SGMII link - which the
driver advertises for that port - drives the select bit from an
uninitialised local. The field names where the port's GMII comes from
rather than the protocol carried on it, so one value covers every interface
uniphy0 drives.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +0200c5adfc683037f65b6189e6cf7d2608349860a85fqualcommax: qca_ppe: select port 4's PCS for every interfaceedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c8cf2d5cc0c4fa747f5ee993caa0f5d1ea0c7d08f1788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: stop advertising RGMII on the SerDes ports
qca_ppe_phylink_get_caps() adds the four RGMII modes to ports 1 to 4, and
then copies the port's supported interfaces into config->pcs_interfaces, so
phylink is told both the MAC and the PCS carry RGMII there. Neither does.
qca_ppe_mac_link_up() and qca_ppe_mac_link_down() have no RGMII arm and
return from their default label; the uniphy PCS driver has no RGMII code at
all. Nor can the ports carry it: every board describes these four with a
pcs-handle into uniphy0, the SerDes block that driver serves, and
ppe_pcs_set_mux_hppe() has no arm for ports 1 to 3 while port 4's select
names uniphy0's PCS0 whatever the interface.
The failure that leaves is silent. phylink_link_up() calls
netif_carrier_on() whether or not the MAC callback did anything, and
mac_link_up() is void, so its early return is not noticed. It returns
before it opens PPE_PORT_BRIDGE_CTRL_TXMAC_EN, the gate the fabric needs
before it will hand the port a frame, and before it enables the port's MAC.
A board describing one of these ports as RGMII would read link up at its
negotiated speed and pass no traffic, with no message anywhere. Once the
mode is not advertised, phylink_validate() rejects it and
phylink_bringup_phy() fails the port with a warning instead.
No qualcommax board describes a PPE port as RGMII: the one rgmii-rxid in
the target's device trees is on a cascaded qca8337's CPU port, whose
PPE-side port is qsgmii. What still reaches a default label after this is
the CPU port's internal link, whose gate qca_ppe_port_enable() opens.
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44): the four user ports come
up at 1000, 1000, 100 and 1000 Mbit/s full duplex, and forwarding, offload
and dmesg are unchanged.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02008cf2d5cc0c4fa747f5ee993caa0f5d1ea0c7d08fqualcommax: qca_ppe: stop advertising RGMII on the SerDes portsedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c66344b9be87ed7405ba3a7c963b9488129a2f0f41788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: leave the MAC at gigabit for an unlisted speed
Neither speed table in qca_ppe_mac_link_up() is exhaustive, and both leave
a speed outside them unhandled: the clock rate is used uninitialised, and
ppe_xgmac_link_up() returns without writing the speed select while its
caller, which cannot see that it did, goes on to enable the MAC and open
the port's transmit gate.
Default both to gigabit.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +020066344b9be87ed7405ba3a7c963b9488129a2f0f4qualcommax: qca_ppe: leave the MAC at gigabit for an unlisted speededittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c245f8d364f2b7d92bb9bc9f0047c1ccd128ceffa1788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: leave the loopback port's transmit gate open
ppe_mac_hw_init() enables the loopback, waits 100 ms for it and opens that
port's PPE_PORT_BRIDGE_CTRL_TXMAC_EN, the gate the fabric needs before it
will hand a port a frame. Two paths shut it again. qca_ppe_setup() walks
every port and clears the bit for all but the CPU port, and the loopback
port is described by no board, so DSA also sees it as unused and calls
port_disable() on it. Nothing reopens it: the port has no phylink, so no
link event ever runs, and the loopback probe configured stays unreachable
for the life of the boot.
Give the bit one owner. ppe_port_bridge_txmac_set() refuses to close the
loopback port's gate, and the setup walk stops writing the bit at all - it
was only ever setting it for the CPU port, whose gate qca_ppe_port_enable()
opens a moment later when DSA enables that port. A user port's gate is
still opened by qca_ppe_mac_link_up() and closed by its link going down.
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44): PPE_PORT_BRIDGE_CTRL(7)
reads 0x0002ff08 before this change and 0x0003ff08 after it, the two
differing only in TXMAC_EN. The CPU port and the four user ports read the
bit set and the two ports no board describes read it clear. Forwarding,
offload and dmesg are unchanged.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +0200245f8d364f2b7d92bb9bc9f0047c1ccd128ceffaqualcommax: qca_ppe: leave the loopback port's transmit gate openedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.c5fe599d77f17923235c0d291361c5f164fa9eb671788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_ppe: leave the probe clocks to devres
The clocks are prepared and enabled by hand, and every failure after that
returned without disabling them - the ioremap, the regmap, the reset
control, the MIB allocation, the per-port clocks and resets, and the switch
registration all leak the enabled clocks on the way out.
devm_clk_bulk_get_all_enabled() registers the disable and unprepare with
devres, which is what qca_edma.c beside this driver already uses. The
unwinding, the error label and the two fields the driver kept the bulk in
all go with it.
Fixes: 142104bb90b3 ("qualcommax: add PPE driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +02005fe599d77f17923235c0d291361c5f164fa9eb67qualcommax: qca_ppe: leave the probe clocks to devresedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe_main.cedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_ppe.h
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.htarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.c30ef6f840927cd4c44ff7761d794212f967920a51788980402000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_edma: map every switch queue to the enabled ring
The engine has sixteen receive rings and this driver brings up exactly one,
the last. Which ring a frame lands in is chosen by the QID2RID table, which
the driver wrote one word of and left the rest of at whatever the block
resets to. Ring zero, the ring a zeroed id names, is never given a base
address and its enable bit is cleared by hardware stop, so any queue whose
id was left at zero points somewhere that cannot deliver.
Fill every word of the table with the ring the per-SoC data names repeated
in each four-bit field, so the value is right whichever field a queue's id
selects. The write is monotone, which is what makes it safe without either
the reset value or the field packing in hand: the enabled ring is the only
place a frame can be delivered, so a queue that delivers today already
resolves to it and is written the value it already had, and a queue that
does not is pointing somewhere that cannot deliver. No frame that arrives
today changes ring.
The table's extent is measured; its packing is not. On IPQ8074 words 0 to
63 hold the value the driver writes and the words sampled above them read
zero, and word 63 holds an arbitrary 32-bit pattern written to it, so the
fill covers the whole table and no bit of a word is hardwired. Which queue
a given word or field serves is not established here, and the fill does not
depend on it.
Which of the two queue-to-ring tables actually selects is settled by the
datapath rather than by a reading. PPE_TM_RING_Q_MAP, which the switch side
programs and which is the only one the kernel's own ppe driver writes -
ppe_queues_to_ring_init() puts the CPU port's unicast queues on ring zero
there - leaves queue zero on ring zero; QID2RID puts it on the enabled
ring; frames arrive. So QID2RID selects, and the switch-side map is
describing something else for rings this driver never brings up.
A single id has held this far because the unicast path to the host is queue
zero: the CPU port's queue base is zero and its priority map folds all
sixteen priorities onto class zero. The CPU port is also given the
multicast queues from 256 up, which is what a flooded frame's copy for the
host is scheduled through, and the driver has never written ids for them.
Tested on IPQ8074 (Xiaomi AX3600, kernel 6.18.44): every word of the table
reads back the enabled ring in all four-bit fields, and the board boots,
dials its PPPoE uplink, bridges and forwards offloaded flows on it.
Fixes: bdb0b722b7f0 ("qualcommax: add EDMA driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:02 +020030ef6f840927cd4c44ff7761d794212f967920a5qualcommax: qca_edma: map every switch queue to the enabled ringedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.cedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.h
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.cf53100d40e1657ced8bce9e3bd0edae1ea5b1d871788980403000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_edma: pad a short frame with its length and its tail
A frame below the transmit minimum is padded with skb_padto(), which zero
-fills the tailroom and returns without moving the tail, and the length is
then advanced by hand. skb->len therefore runs past the data a head
reallocation copies: pskb_expand_head(), three lines below and reached
whenever the frame arrives cloned or short of headroom, copies only as far
as the tail and leaves the pad uninitialised in the new head. The
descriptor still names the padded length, so those bytes go on the wire.
skb_put_padto() advances the tail with the length, which is the whole
difference. It also folds in the length test the call site made, since it
no-ops on a frame that is already long enough.
Fixes: bdb0b722b7f0 ("qualcommax: add EDMA driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:03 +0200f53100d40e1657ced8bce9e3bd0edae1ea5b1d87qualcommax: qca_edma: pad a short frame with its length and its tailedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.ca9adfbf98fb1a39c82e99580e793e76c01d89fa01788980403000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_edma: refuse a frame before its preheader is pushed
The transmit routine prepends the 32-byte preheader and only then tests
whether the descriptor's slot still holds an uncompleted frame. A frame
refused there goes back to the qdisc already carrying the preheader, and
the requeue pushes a second one: the descriptor names a length that no
longer describes the frame, and the headroom the push consumed is gone.
Both refusals now precede the push, where the ring-full test already sat.
The slot test depends on nothing between the two points, so the accepted
path is unchanged.
Fixes: bdb0b722b7f0 ("qualcommax: add EDMA driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:03 +0200a9adfbf98fb1a39c82e99580e793e76c01d89fa0qualcommax: qca_edma: refuse a frame before its preheader is pushededittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.ce3c00e95ca170afaa8e95f8a63cd71ca1f65202c1788980403000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_edma: free a completed frame with the budget of its caller
edma_clean_tx() passes its loop bound to napi_consume_skb() as the NAPI
budget. A non-zero budget tells that helper it is running inside a poll and
frees the frame into the per-CPU NAPI cache, which is only safe from
softirq context. edma_rings_drain() calls the same routine from process
context with INT_MAX - on an MTU change that alters the receive page order,
and on the probe error and remove paths - so a transmit completion on the
same CPU can interleave with the cache update.
The budget the poll was given becomes an argument of its own, zero on the
drain, which routes those frees through dev_consume_skb_any() instead.
Fixes: bdb0b722b7f0 ("qualcommax: add EDMA driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:03 +0200e3c00e95ca170afaa8e95f8a63cd71ca1f65202cqualcommax: qca_edma: free a completed frame with the budget of its calleredittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.cf63a9ccd4cc5b4ff30066538924014cad5e5e2b41788980403000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_edma: recheck the transmit ring once it is stopped
The queue is stopped from a consumer index read before the descriptor was
published, and nothing re-reads it afterwards. A completion that drains the
ring in that window runs the poll while the queue still reads as running,
so the poll does not wake it, and the stop that follows has no completion
left behind it: the interface stops transmitting until it is taken down.
netif_txq_try_stop() carries the barrier and the recheck. The indices the
frame was placed from still decide whether to stop at all, since a consumer
index only ages into reporting less room than the ring has, so a frame that
does not fill the ring costs no extra register read.
A refused frame reaches the same window from the other side. Both
NETDEV_TX_BUSY returns leave a ring the engine is still draining, and the
queue was stopped by the caller after the transmit lock had been dropped,
with no recheck at all. The refusals stop the queue themselves, under the
lock and on the state they were decided from, and the caller no longer
touches the queue state.
The two refusals do not name the same resource. A free descriptor count
measures a full ring, but a taken store slot outlives the descriptor that
named it: the engine releases a descriptor as soon as it reads it, while
only the completion clears the slot. A recheck taken from the descriptors
alone restarts the queue on a resource the refused frame still lacks, and
the frame returns to a running queue, which turns the refusal into a retry
rather than back pressure. The recheck reports no room while the slot is
taken.
The completion side takes the same count against the same threshold
through __netif_txq_completed_wake(), which carries the barrier the recheck
pairs with and reports the completed frames to BQL. That wake is a second
writer of a queue state the control path also stops, so it is held back on
a ring drain, which runs with the queue deliberately stopped and the rings
about to be freed and is not a poll.
Measured on an ipq807x AX3600: three 20 s sixteen-stream transfers through
this ring carry 818, 853 and 824 Mbit/s with no frame dropped on the
interface, the queue running at the end, every switch port up and the log
clean.
Fixes: bdb0b722b7f0 ("qualcommax: add EDMA driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:03 +0200f63a9ccd4cc5b4ff30066538924014cad5e5e2b4qualcommax: qca_edma: recheck the transmit ring once it is stoppededittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.c
- target/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.c8cdd105d31ca02fd2c3045a4ede7eeb6ecee3e9d1788980403000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: qca_edma: stop the poll before the queue on an MTU change
A transmit completion wakes a stopped queue, so the poll is the second
writer of the queue state that the MTU change stops. netif_tx_disable()
ran first, and a completion landing after it woke the queue and scheduled
the qdisc; napi_disable() then returned as soon as the poll cleared its
scheduled bit, while the poll thread was still inside the local_bh_enable()
that runs the transmit softirq it had queued - against the rings the drain
below frees.
Put the poll down first.
Measured on an ipq807x AX3600: sixteen mtu changes across the receive page
-order boundary, run under an eight-stream transfer, complete with the
transfer carrying 763 Mbit/s through them, the interface up, every switch
port up and the log clean.
Fixes: bdb0b722b7f0 ("qualcommax: add EDMA driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:03 +02008cdd105d31ca02fd2c3045a4ede7eeb6ecee3e9dqualcommax: qca_edma: stop the poll before the queue on an MTU changeedittarget/linux/qualcommax/files/drivers/net/ethernet/qualcomm/qca_edma.c
- target/linux/qualcommax/files/drivers/net/pcs/pcs-qca-uniphy.c8939d5654a772589b481cf5314b42477736204481788980403000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: pcs-qca-uniphy: report a USXGMII speed only once the link is up
qca_uniphy_pcs_get_state_usxgmii() reads the speed out of the USXGMII code
word without consulting the link bit beside it, so a word the partner has
not filled in yet is decoded as a speed and handed to phylink as a resolved
link. The field is read into state->an_complete and never used again.
Report no link until that bit is set, which is the shape mainline's
xpcs_get_state_c73() has for the same word:
drivers/net/pcs/pcs-xpcs.c, xpcs_get_state_c73():
state->an_complete = xpcs_aneg_done_c73(xpcs, state, ...);
if (!state->an_complete) {
state->link = false;
return 0;
}
This arm needs a USXGMII partner and the bench has no 10G port, so it is
not runtime tested here.
Fixes: 05c180511dda ("qualcommax: add UNIPHY PCS driver")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25084
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:00:03 +02008939d5654a772589b481cf5314b4247773620448qualcommax: pcs-qca-uniphy: report a USXGMII speed only once the link is upedittarget/linux/qualcommax/files/drivers/net/pcs/pcs-qca-uniphy.c
- target/linux/qualcommax/ipq50xx/base-files/etc/hotplug.d/firmware/11-ath11k-caldatatarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/02_networktarget/linux/qualcommax/ipq50xx/base-files/lib/upgrade/platform.shpackage/firmware/ipq-wifi/Makefiletarget/linux/qualcommax/ipq50xx/base-files/lib/preinit/09_mount_tp_datatarget/linux/qualcommax/dts/ipq5018-archer-ax55-v1.dtstarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/01_ledstarget/linux/qualcommax/image/ipq50xx.mkpackage/boot/uboot-tools/uboot-envtools/files/qualcommax_ipq50xx8ac63a1c3551fcb3a903ec347e84c1fd1ad6142a1788981383000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: add support for TP-Link Archer AX55 v1
TP-Link Archer AX55 v1 is an IPQ5018 Wi-Fi 6 router.
Hardware:
SoC: Qualcomm IPQ5018 (dual Cortex-A53)
RAM: 512 MiB
Flash: 128 MiB SPI-NAND (dual firmware slots)
Switch: Realtek RTL8367S (5x GbE), 2.5G HSGMII trunk to gmac1
WiFi: IPQ5018 2.4 GHz + QCN6122 5 GHz (ath11k)
USB: 1x USB 3.0 port, SuperSpeed, using the IPQ5018 SS uni PHY;
the port's 5 V rail is a GPIO-switched regulator wired as the
PHY's vdd-supply, the way the MR5500 does it
Button: Reset, WPS/Wi-Fi
LED: power, LAN, WAN (green/orange), 2.4G, 5G, USB
All five front jacks are RTL8367S ports (DSA): blue "WAN" = wan,
LAN1-4 = lan1..lan4, over the 2.5G HSGMII trunk.
The factory MAC is the "default-mac" file in the tp_data UBIFS volume
(there is no raw nvmem cell for it). The volume is attached and mounted
read-only during preinit, so board.d assigns the wired MACs (label MAC
for lan/eth0, +1 for wan) the usual way and the ath11k caldata hotplug
derives the Wi-Fi MACs (+2/+3) from the same mount - the same scheme
the mt7981 archer-ax80-v1 uses for its tp_data. gmac1 has no nvmem MAC
source, so the DSA conduit is pinned to the label MAC in board.d to
keep it stable across boots.
The board data files live in firmware_qca-wireless, where they were
merged as f2c37a6b9d1d; this commit pins the ipq-wifi package to that
revision and adds the package entry for the board.
Note on revisions: some units labelled "v1" carry an RTL8367D-family
switch (chip id 0x6642) instead of the RTL8367S. rtl8365mb cleanly
declines it ("unrecognized switch"), so such a unit boots with no wired
ports, and with Wi-Fi off by default it is only reachable via the
vendor web recovery (or serial). RTL8367D support in rtl8365mb is being
worked on by others; until it lands the wiki page carries a prominent
warning to identify the switch before flashing. v2/v4 are entirely
different hardware and are not covered by this image.
Installation (serial console on the JP1 header, 115200 8N1, 1.8 V; note
the RX trace is gapped and must be bridged to type): interrupt U-Boot,
TFTP-boot the initramfs image to 0x44000000, "bootm", then "sysupgrade -n".
A serial-free path (a telnet-enabled resigned stock image flashed from the
vendor web UI, then writing the OpenWrt image to the inactive slot) is
documented on the device wiki page; that path consumes the
initramfs-factory.ubi artifact, which is the initramfs kernel wrapped in
a UBI image so it can be written straight into the inactive rootfs
partition with mtd from the running stock firmware.
Recovery to stock: hold Reset while powering on, set the PC to
192.168.0.10, and upload an official signed TP-Link image at
http://192.168.0.1.
Signed-off-by: Stanislaw Pal <kuncy7@gmail.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/24197
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:16:23 +02008ac63a1c3551fcb3a903ec347e84c1fd1ad6142aqualcommax: add support for TP-Link Archer AX55 v1editpackage/firmware/ipq-wifi/Makefileaddtarget/linux/qualcommax/dts/ipq5018-archer-ax55-v1.dtsaddtarget/linux/qualcommax/ipq50xx/base-files/lib/preinit/09_mount_tp_dataedittarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/02_networkedittarget/linux/qualcommax/image/ipq50xx.mkedittarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/01_ledseditpackage/boot/uboot-tools/uboot-envtools/files/qualcommax_ipq50xxedittarget/linux/qualcommax/ipq50xx/base-files/etc/hotplug.d/firmware/11-ath11k-caldataedittarget/linux/qualcommax/ipq50xx/base-files/lib/upgrade/platform.sh
- target/linux/generic/config-filterb886a6ca0c7fd803703650483e36cb04fa13287a1788982597000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comgeneric: filter: add RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS
CONFIG_RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS is autodetected
based on rustc version, so filter it out of target configs.
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:36:37 +0200b886a6ca0c7fd803703650483e36cb04fa13287ageneric: filter: add RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONSedittarget/linux/generic/config-filter
- target/linux/econet/patches-6.18/046-v7.3-net-phy-mediatek-add-EcoNet-EN7528-PHY-support.patchtarget/linux/econet/en7528/config-6.186150f5a5ad58efc85073ef53750a58b8f71fb5be1788982781000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comeconet: en7528: add support for the EN7528 built-in Ethernet PHYs
The EcoNet EN7528 embeds four Gigabit Ethernet PHYs (PHY ID 0x03a29491)
behind its built-in MT7530 switch. Without a driver of their own they
fall back to the generic PHY driver, which cannot drive the LED pins of
the PHYs.
Backport the upstream driver support and enable MEDIATEK_GE_SOC_PHY.
The PHYs use the same LED register layout as the other SoC PHYs handled
by that driver, but their LED controller powers up with its external
control disabled, so the driver enables it from config_init.
Backported from upstream commit
https://github.com/torvalds/linux/commit/b6e2649fff15a17689851b30e5415a3aae2b516e
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25098
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:39:41 +02006150f5a5ad58efc85073ef53750a58b8f71fb5beeconet: en7528: add support for the EN7528 built-in Ethernet PHYsedittarget/linux/econet/en7528/config-6.18addtarget/linux/econet/patches-6.18/046-v7.3-net-phy-mediatek-add-EcoNet-EN7528-PHY-support.patch
- target/linux/econet/dts/en7528_dasan_h660gm-a.dtsitarget/linux/econet/dts/en7528_dasan_h660gm-a-generic.dtstarget/linux/econet/dts/en7528_jiofiber_jcow414.dtstarget/linux/econet/dts/en7528.dtsitarget/linux/econet/dts/en7528_jiofiber.dtsitarget/linux/econet/dts/en7528_dasan_h660gm-a-airtel.dtstarget/linux/econet/base-files/etc/board.d/01_ledstarget/linux/econet/dts/en7528_jiofiber_jcow407.dtsf3614686abca9e37249c9203822858a5cdbef8ce1788982781000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comeconet: en7528: offload the LAN LEDs to the built-in GPHYs
The LAN LEDs of the EN7528 boards are wired to the LED pins of the GPHYs
sitting behind the switch ports, but were described as plain GPIOs, so
they were left under software control and stayed dark.
Add the LED nodes to the GPHYs of the SoC .dtsi, mux the LED pins to the
matching phyN_ledM function of the pin controller, and replace the
gpio-leds nodes of the LAN LEDs with references to the PHY LEDs. The
LEDs are then driven by the PHY itself, without any CPU involvement.
The JioFiber boards have both LED pins of every GPHY wired up, giving a
bicolour LED per socket. The H660GM-A boards only have the LED1 pins
wired, as the LED0 pins are used as GPIOs for the other LEDs and for the
WPS button; the amber LEDs of the generic variant stay plain GPIOs.
Add board.d/01_leds to hook the LEDs up to the netdev trigger, which the
PHY driver offloads to the hardware.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25098
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-09-09 21:39:41 +0200f3614686abca9e37249c9203822858a5cdbef8ceeconet: en7528: offload the LAN LEDs to the built-in GPHYsedittarget/linux/econet/dts/en7528_dasan_h660gm-a-generic.dtsedittarget/linux/econet/dts/en7528.dtsiedittarget/linux/econet/dts/en7528_jiofiber_jcow414.dtsedittarget/linux/econet/dts/en7528_jiofiber.dtsiaddtarget/linux/econet/base-files/etc/board.d/01_ledsedittarget/linux/econet/dts/en7528_dasan_h660gm-a-airtel.dtsedittarget/linux/econet/dts/en7528_dasan_h660gm-a.dtsiedittarget/linux/econet/dts/en7528_jiofiber_jcow407.dts
githttps://taiha.net/jenkins/user/jonasjonasjonashttps://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausenhttps://taiha.net/jenkins/user/robimarkorobimarkorobimarkohttps://taiha.net/jenkins/user/danieldanieldaniel