OpenWRT

Recent Commits

• Mieczyslaw Nalewaj(04 Jun 26)

  mediatek: remove RTL8367S_GSW driver and disable swconfig on mt7622 All mt7622 devices using the RTL8367S switch have been migrated to the generic rtl8365mb DSA driver. Remove the now-unused RTL8367S_GSW driver and disable swconfig in the mt7622 kernel config, since no device in this target needs it anymore. The driver and its Kconfig symbol are shared across the mediatek target, so this also drops the tree-wide files/drivers/net/phy/rtk/ sources and the now-dead "# CONFIG_RTL8367S_GSW is not set" line from the filogic, mt7623 and mt7629 kernel configs. Signed-off-by: Mieczyslaw Nalewaj <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24861 Signed-off-by: Jonas Jelonek <[email protected]>

• Mieczyslaw Nalewaj(22 Aug 26)

  mediatek: mt7622: convert devices with RTL8367S switch to DSA Migrate Buffalo WSR-2533DHP2, ELECOM WRC-2533GENT and TOTOLINK A8000RU from swconfig to DSA. These devices use an external Realtek RTL8367S switch handled by the rtl8365mb DSA driver. Per-device changes: - Drop the proprietary mediatek,rtk-gsw node - Add realtek,rtl8365mb DSA switch with ports lan1-lan4, wan and CPU - Move CPU port to gmac0 at 2500base-x (HSGMII) - Remove gmac1 (was 5u@eth1 in swconfig; DSA uses single CPU port) - Drop unused rgmii_via_gmac2 pin group - Replace swconfig with kmod-dsa-rtl8365mb - Bump DEVICE_COMPAT_VERSION (config migration not possible) - Remove swconfig board setup from 02_network - Disable CONFIG_RTL8367S_GSW in mt7622 kernel config CPU link / bandwidth notes: - Buffalo WSR-2533DHP2 and TOTOLINK A8000RU: already used 2500base-x on gmac0 before this change; aggregate bandwidth stays the same. - ELECOM WRC-2533GENT: gmac0 moves from SGMII (1G) to 2500base-x (HSGMII). The swconfig setup previously used two 1G CPU links (gmac0 + gmac1) for 2 Gbps aggregate; DSA collapses this to a single 2.5 Gbps link. MAC address assignment notes: - Buffalo WSR-2533DHP2: WAN uses base MAC + 1, gmac0/LAN uses base MAC (previously the WAN MAC existed on the implicit eth1/gmac1 interface) - ELECOM WRC-2533GENT: WAN inherits CPU MAC via DSA conduit (original gmac1 had no nvmem-cells assignment) - TOTOLINK A8000RU: WAN reuses macaddr_factory_24 (previously gmac1) Signed-off-by: Mieczyslaw Nalewaj <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24861 Signed-off-by: Jonas Jelonek <[email protected]>

• Mark Abe(03 Sept 26)

  realtek: dsa: rtl839x: don't clobber adjacent LOG counter rtl839x_packet_cntr_clear() has the same defect as the rtl838x variant: it zeroes one register of a shared two-register LOG table entry and writes the entry back without reading it first, so the counter sharing that entry is overwritten with stale register-cache data. Read the entry before modifying one half, mirroring the same fix already applied to rtl930x_packet_cntr_clear(). Signed-off-by: Mark Abe <[email protected]> Link: https://github.com/openwrt/openwrt/pull/25005 Signed-off-by: Markus Stockhausen <[email protected]>

• Mark Abe(03 Sept 26)

  realtek: dsa: rtl838x: don't clobber adjacent LOG counter rtl838x_packet_cntr_clear() zeroes one of the two registers that make up a LOG table entry and then writes the whole entry back without reading it first, wiping the adjacent counter with whatever stale data is in the table register cache. Two 32-bit packet counters share one entry, so the counter next to the one being cleared is lost. Read the entry before modifying one half, mirroring the same fix already applied to rtl930x_packet_cntr_clear(). Signed-off-by: Mark Abe <[email protected]> Link: https://github.com/openwrt/openwrt/pull/25005 Signed-off-by: Markus Stockhausen <[email protected]>

• Daniel Golle(03 Sept 26)

  linux-firmware: mark aeonsemi-as21xxx-firmware as 'nonshared' In order for the firmware package to depend on the corresponding kmod it needs to be built within the same builtbot phase for the dependency to land in the package metadata. Select 'nonshared' to force the firmware to also get built as part of phase1. Fixes: 1446eff887 ("mediatek: filogic: bpi-r4-pro-8x: add aeonsemi phy to bpi-r4-pro-8x") Signed-off-by: Daniel Golle <[email protected]>

• Hideo Sumi(02 Sept 26)

  wifi-scripts: silence iw antenna/distance failures like shell did The shell mac80211.sh ran both of these with >/dev/null 2>&1: iw phy "$phy" set antenna $txantenna $rxantenna >/dev/null 2>&1 iw phy "$phy" set distance "$distance" >/dev/null 2>&1 The ucode rewrite dropped the redirect, so on any driver without ->set_coverage_class every wifi up now logs netifd: radio0 (3302): command failed: Not supported (-95) with no indication of which command failed. Neither return value is checked, so the message is pure noise -- but it reads like wifi up failed, and on ath12k/IPQ5332 it cost real debugging time before the line was traced back to iw.c:616 rather than to the driver. Restore the redirect. distance defaults to 0 and antenna to 0xffffffff, so both calls run on every setup for every radio. Signed-off-by: Hideo Sumi <[email protected]>

• Tianling Shen(03 Sept 26)

  qualcommax: ipq60xx: enable lan4 port for link nn6000v2 The swport5 node was disabled by mistake during the PPE conversion. Fixes: f50435627d37 ("qualcommax: ipq60xx/ipq807x: convert to PPE networking stack") Signed-off-by: Tianling Shen <[email protected]> Link: https://github.com/openwrt/openwrt/pull/25006 Signed-off-by: Robert Marko <[email protected]>

• Rosen Penev(04 Jul 26)

  ath79: mikrotik: convert to DSA Use qca8k to drive the external switches on these devices. Signed-off-by: Rosen Penev <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24066 Signed-off-by: Jonas Jelonek <[email protected]>

• Chad Monroe(02 Sept 26)

  mediatek: use lowercase SmartRG dts filenames Device dts filenames use the lowercase device name across the tree; the SmartRG boards were the only ones that spell the SDG model prefix in uppercase. Rename the files and adjust the DEVICE_DTS values and includes. No functional changes. Signed-off-by: Chad Monroe <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24679 Signed-off-by: Jonas Jelonek <[email protected]>

• Chad Monroe(21 Jul 26)

  mediatek: filogic: add Adtran SmartRG Mount Rainier series Common specifications: * MediaTek MT7987A (4x Cortex-A53) * 4 GiB eMMC * 1 GiB DDR4 RAM * 1x 2500M/1000M/100M/10M WAN port (MaxLinear MXL86211C PHY) * 2x 2500M/1000M/100M/10M LAN ports (MaxLinear MXL86211C PHY, MT7987 built-in 2.5G PHY) * 3x LED (green/amber/white) for each Ethernet port * 2 buttons (Reset, Mesh/WPS) * uC-controlled RGB LED via I2C * USB 2.0 type A port * 3.3V-level 115200 baud UART console * 12V 3A DC barrel jack power input SDG-8712: MT7992 dual-band 802.11be Wi-Fi (2.4G 4T4R, 5G 4T5R) SDG-8732: MT7996 tri-band 802.11be Wi-Fi (2.4G 2T2R, 5G 3T3R, 6G 3T3R) MAC addresses (base MFG_MAC from the mfginfo partition; the nvmem cell index in the DTS is added to the base): wan xx:xx:xx:xx:xx:x0 MFG_MAC lan1 xx:xx:xx:xx:xx:x1 MFG_MAC + 0x1 lan2 xx:xx:xx:xx:xx:x1 MFG_MAC + 0x1 2.4G xx:xx:xx:xx:xx:x4 MFG_MAC + 0x4 5G xx:xx:xx:xx:xx:xa MFG_MAC + 0xa 6G xx:xx:xx:xx:xx:x6 MFG_MAC + 0x6 (SDG-8732 only) Both models are also available in versions including 1x FXS POTS interface for analog phones. Those interfaces are not supported by OpenWrt. Installation: 1. Prepare a TFTP server at 192.168.1.10 and serve the OpenWrt initramfs image, renamed to "openwrt.<engnum>" for the model being installed: openwrt.440: SDG-8712 openwrt.442: SDG-8732 2. Connect to LAN2. 3. Connect to the UART port. 4. Power on the device and type "st" to enter the U-Boot command line. The window to do that might be very short (below 1s), so type it as soon as the "U-Boot ..." string appears. 5. Run "setenv boot_mode openwrt; saveenv" to boot from OpenWrt partition by default. 6. Run "bootmenu" and select option 6 (TFTP openwrt image and boot); "run boot5" is a shortcut for the same. This downloads openwrt.<engnum> from the TFTP server and boots it. 7. After OpenWrt finishes booting, download the OpenWrt sysupgrade image and write it to eMMC using "sysupgrade". 8. After sysupgrade finishes writing, the device reboots into OpenWrt. When the front LED is solid white the device is ready for configuration. Signed-off-by: Chad Monroe <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24679 Signed-off-by: Jonas Jelonek <[email protected]>

• Gennaro Cimmino(31 Aug 26)

  realtek: dsa: support changing the MTU on RTL83xx ports Both families limit the frame length of the whole switch in a single register instead of one per port, so the operation programs it from the largest MTU of any user port rather than from the port it is handed. Lowering one port therefore lowers the limit only once no other port asks for more. RTL838x mirrors that register in a second one and the vendor SDK writes both, in dal_maple_switch_maxPktLenLinkSpeed_set(), so this does the same. These are the first users of the switch-wide path the infrastructure came with. With their entries in place an MTU can be set on any port of any of the four families, and the maxima are the ones the ethernet driver already uses: 10000 on RTL838x, which is what its datasheet gives and what its rmon range counts, and 12288 on RTL839x. Nothing programmed these registers until now, so a port keeps whatever value it comes up with, and a switch that today forwards frames larger than its ports announce stops doing so once they are programmed at the default MTU. Asking for them by configuring the MTU works from here on. Not tested on hardware: no RTL838x or RTL839x here. Assisted-by: Claude:claude-opus-5 Signed-off-by: Gennaro Cimmino <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24400 Signed-off-by: Markus Stockhausen <[email protected]>

• Gennaro Cimmino(31 Aug 26)

  realtek: dsa: support changing the MTU on RTL931x ports RTL931x holds the same per port maximum L2 frame length register as RTL930x, with the same field layout: two 14 bit lengths, the high speed one in [13:0] and the 10/100M one in [27:14], and the tag inclusion bit in [28]. Only the placement differs. RTL930x keeps it inside the 64 byte per port MAC block, while RTL931x has a compact array of its own at 0x5554, so the family needs nothing beyond the callback and its largest frame. The GPL SDK register list gives that address and covers ports 0 to 55 with it, leaving out the CPU port, 56. The stride follows from the array spanning the 224 bytes up to the next register, MAC_DBG_SEL_CTRL at 0x5634: 56 words of four bytes. The CPU port needs no row anyway, as the ethernet driver programs both of its directions from MAC_L2_CPU_MAX_LEN_CTRL, unlike RTL930x whose equivalent register holds one direction and leaves the other in the row of the array. The shared operation returns before the write for the CPU port, so 0x5634 is never addressed. Nothing programmed those registers until now, so a port keeps whatever value it comes up with while its netdev announces an MTU of 1500. Not tested on hardware: no RTL931x here. Assisted-by: Claude:claude-opus-5 Signed-off-by: Gennaro Cimmino <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24400 Signed-off-by: Markus Stockhausen <[email protected]>

• Gennaro Cimmino(31 Aug 26)

  realtek: dsa: support changing the MTU on RTL930x ports Fill in the config entries for RTL930x: the callback returning the register that holds the MAC maximum accepted L2 frame length of a port, one per user port at 0x326C + (port << 6) from the reverse engineered maps at svanheule.net, and the largest frame the family switches, from which the advertised maximum MTU is derived. The programmed limit is the MTU plus Ethernet header, two stacked VLAN tags (802.1ad QinQ) and FCS. RTL838x, RTL839x and RTL931x carry no entries yet, so they keep refusing MTU changes and advertising the ether_setup() default. This changes what a user port accepts. Nothing programmed these registers until now, as the ethernet driver only writes the CPU port row of the same register, so a port kept whatever value it came up with while its netdev announced an MTU of 1500. Measured on an RTL9303, frames probed from a host with ping -M do and the ports configured through UCI alone. On main a port announces a maximum MTU of 1500 and takes frames up to 1530 bytes, which is the CPU port limit the ethernet driver derives from the conduit MTU, 1504 plus the overhead, rather than anything the port enforces; asking for an MTU of 9000 leaves every port at 1500 and the boundary at 1530. With this commit the port announces 12258 and the boundary follows the MTU: 1526 bytes by default, 9026 with the ports at 9000, and 1526 again once the MTU is removed from the configuration. Probing the same boundary through VLAN devices, with the ports at 9000, gives 9030 bytes carrying one 802.1q tag and 9026 carrying a 802.1ad tag with a 802.1q one inside. So the eight bytes the limit sets aside for stacked tags are what the QinQ case takes, and a single tagged frame has four of them to spare. Assisted-by: Claude:claude-opus-5 Signed-off-by: Gennaro Cimmino <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24400 Signed-off-by: Markus Stockhausen <[email protected]>

• Gennaro Cimmino(31 Aug 26)

  realtek: dsa: add infrastructure for changing the port MTU Add the port_change_mtu and port_max_mtu operations, wire them into both the RTL83xx and RTL93xx dsa_switch_ops, and put in place what the per family support needs: the encoding of the MAC maximum length fields, the config entries naming the register a family limits its frames with, and the largest frame it switches. Nothing is enabled here. No config carries a largest frame yet, so port_max_mtu keeps returning the ether_setup() default the user netdevices already advertised, and port_change_mtu keeps returning the -EOPNOTSUPP the DSA core returns on its own while the operation is absent. The families are turned on one at a time in the commits that follow, each filling in nothing but its own config entries. The CPU port is skipped in the shared operation rather than in a family callback, though the reason differs. On RTL930x its row of that register is the one the ethernet driver programs from the conduit MTU, and the two values would not agree: the DSA core raises the conduit MTU by the tagger overhead but hands this operation the plain largest user MTU, and it does so afterwards, so the write here would land last and shorten the limit by exactly that overhead. On the other three families the CPU port has no row of its own. Skipping it in one place covers both cases. Families whose limit is one register for the whole switch are served by the same operation, programming it from the largest MTU of any user port; the first users of that path are in the last commit of the series. The DSA core takes a different route once the operations exist: instead of bailing out early it sets the conduit MTU and rolls it back, so the conduit change_mtu operation runs twice per user port at probe, and twice more on any MTU request this commit then refuses. It is only called at all because the ethernet driver has one, and at probe it touches no hardware, as the conduit is still down at that point and the operation returns before programming anything. Not tested on hardware in this shape. What was tested on an RTL9303 is what it reduces to while no config carries a largest frame, the two operations as bare stubs returning those same two values: the advertised maximum, the errors an MTU change returns, the conduit at 1504, the boot log and ordinary traffic were all indistinguishable from the tree without it. Assisted-by: Claude:claude-opus-5 Signed-off-by: Gennaro Cimmino <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24400 Signed-off-by: Markus Stockhausen <[email protected]>

• Felix Fietkau(02 Sept 26)

  hostapd: address a station on the link it associated over Every link of an AP MLD can hold an entry for a station while only the association link says where it is listening. Taking the first link that has an entry sent the frame out on a link the station is not on, so a BTM Request addressed to a station on the 5 GHz link went out on 2.4 GHz and the station never saw it. Prefer the link whose entry names it as the association link, and keep any other entry only as a fallback for a station no link claims. Signed-off-by: Felix Fietkau <[email protected]>

• Felix Fietkau(02 Sept 26)

  hostapd: stop building the MBO transition IE from uninitialised values hostapd_bss_transition_request() left mbo_reason, cell_pref and reassoc_delay uninitialised and assigned them only when the caller named them, while hostapd_bss_tr_send() built the MBO attributes from all three unconditionally. A caller that names none of them, which is every caller that only wants a plain BTM Request, therefore had whatever the stack held validated and then written into the frame. Where the leftovers failed validation the request was refused with an invalid argument and no BTM Request frame was transmitted at all; where they passed, the frame carried a random transition reason and cellular preference. Which of the two happened varied between calls, so client steering failed intermittently with no diagnostic. Initialise the three, and build the attributes only when the caller asked for MBO. Name the cellular preference constants while touching the validation. Signed-off-by: Felix Fietkau <[email protected]>

• Felix Fietkau(01 Sept 26)

  hostapd: find a station on any link of an AP MLD in ubus methods A station associates over one link of an AP MLD and its sta_info lives on that link's BSS. A ubus method resolves its hostapd_data from the object it arrived on, and only the BSS that registered the shared interface name owns an object, so a method addressed to a station on any other link looked it up on the wrong BSS. bss_transition_request returned NOT_FOUND for those stations, so no BTM Request frame was ever transmitted: hostapd's bss_transition_request_tx counter stayed put across a whole run of client steering mandates. del_client likewise failed to deauthenticate them, which left association control unable to block a client of an AP MLD. Walk the affiliated links, as hostapd_get_sta_ies_sta() already does for the association frames, and act on the BSS that holds the station. Signed-off-by: Felix Fietkau <[email protected]>

• Felix Fietkau(01 Sept 26)

  hostapd: send every ubus notification of an AP MLD to the subscribed object The BSSes of an AP MLD share one interface name, so only the first BSS registers hostapd.<iface> and holds the subscribers. ubus_add_object() fails for every other link and its return value is discarded, leaving those links with an object that never has a subscriber. hostapd_ubus_notify_obj() already resolves this, but only the generic hostapd_ubus_notify() used it. Every other emitter still tested and notified hapd->ubus.obj directly, so an event raised on a link other than the first was dropped without a trace. sta-authorized is the one that hurts: a station that associates over any link but the first is never announced. umap-rrmd builds its station table from that notification, so it never learns the station, and client steering fails with "rrmd accepted 0 of 1 mandate STAs" for every client of an AP MLD. bss-transition-response, beacon-report and the association decision in hostapd_ubus_handle_event() are lost the same way. Route them all through hostapd_ubus_notify_obj(). A BSS that is not an MLD link, or one whose own object has subscribers, is unaffected. Signed-off-by: Felix Fietkau <[email protected]>

• Jonas Jelonek(01 Sept 26)

  realtek: increase memory size for Zyxel XMG1915 The commit adding support for the Zyxel XMG1915-10E didn't carry a dedicated memory node in the DTS. The device has actually 256MiB, but because this node is missing from the DTS, it falls back to the 128MiB-sized memory node in rtl930x.dtsi. The commits refactoring support for XMG1915-10E and adding support for XMG1915-10EP didn't fix that either. Thus, add the needed memory node to unlock the full memory. Fixes: 94607d6285cc ("realtek: add support for Zyxel XMG1915-10E") Fixes: bdddc753c5a1 ("realtek: add support for Zyxel XMG1915-10EP") Link: https://github.com/openwrt/openwrt/pull/24984 Signed-off-by: Jonas Jelonek <[email protected]>

• Andrea Pesaresi(27 Aug 26)

  kernel: 6.18: backport ksmbd TCP connection fixes Backport upstream fixes that enable TCP keepalive on accepted ksmbd connections and preserve TCP timers for kernel sockets. This prevents stale ESTABLISHED and FIN-WAIT-1 sockets from exhausting the per-IP connection limit after clients disconnect unexpectedly. Refresh the patches against Linux 6.18.44. Link: https://git.kernel.org/torvalds/c/56549c18a4f75309161ca780feaa4d17904e3ee9 Link: https://git.kernel.org/torvalds/c/80b6367ec37faf61fbd11aae6fae64c51faa5bba Signed-off-by: Andrea Pesaresi <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24935 Signed-off-by: Jonas Jelonek <[email protected]>

• Andrea Pesaresi(27 Aug 26)

  kernel: 6.12: backport ksmbd TCP connection fixes Backport upstream fixes that enable TCP keepalive on accepted ksmbd connections and preserve TCP timers for kernel sockets. This prevents stale ESTABLISHED and FIN-WAIT-1 sockets from exhausting the per-IP connection limit after clients disconnect unexpectedly. Refresh the patches against Linux 6.12.105. Link: https://git.kernel.org/torvalds/c/56549c18a4f75309161ca780feaa4d17904e3ee9 Link: https://git.kernel.org/torvalds/c/80b6367ec37faf61fbd11aae6fae64c51faa5bba Signed-off-by: Andrea Pesaresi <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24935 Signed-off-by: Jonas Jelonek <[email protected]>

• George Moussalem(27 Aug 26)

  qualcommax: ipq50xx: mr5500: switch qca8k to external MDIO bus With below patch merged upstream, the qca8k driver can use the external MDIO bus instead of its internal one. This fixes the issue of the LED names when an external MDIO bus is used. LED names were prefixed with "(efault)" because the driver was hardcoded to use the internal MDIO bus when naming the LEDs as the internal bus was NULL. This forced the LEDs to be populated under the internal bus. In addition, the internal MDIO will likely be removed from the driver in the future. So let's move the PHYs from the internal MDIO bus to the external bus, the one from the SoC, in line with all other boards, and rename the LED names. link: https://github.com/torvalds/linux/commit/0b7b378ce6cafbb948786cb6f17f406d94016c8c.patch Signed-off-by: George Moussalem <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24927 Signed-off-by: Robert Marko <[email protected]>

• Jonas Jelonek(01 Sept 26)

  realtek: fix IMAGE_SIZE for TL-ST1008F Fix the image size limit for TP-Link TL-ST1008F to 29696k. The firmware partition has a size of 0x1d00000, thus the previous limit is wrong. It was just copied without proper checking from another device. Signed-off-by: Jonas Jelonek <[email protected]>

• Greg Patrick(31 Aug 26)

  realtek: fix NicGiga S100-0800S-M flash size The firmware partition and IMAGE_SIZE were inherited from rtl9303_tplink_tl-st1008f-v2.dts and describe a 32 MiB SPI-NOR. This board has a 16 MiB chip, so the kernel truncates the partition on every boot: [ 0.679519] 6 fixed-partitions partitions found on MTD device spi0.0 [ 0.687292] Creating 6 MTD partitions on "spi0.0": [ 0.740421] mtd: partition "firmware" extends beyond the end of device "spi0.0" -- size truncated to 0xd00000 The chip identifies itself as a Winbond W25Q128 (128 Mbit / 16 MiB): # cd /sys/bus/spi/devices/spi0.0/spi-nor # cat jedec_id manufacturer partname ef4018 winbond w25q128 and the resulting partitions end exactly at the top of a 16 MiB chip: dev: size erasesize name mtd0: 000e0000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00010000 00010000 "u-boot-env2" mtd3: 00100000 00010000 "jffs2-cfg" mtd4: 00100000 00010000 "jffs2-log" mtd5: 00d00000 00010000 "firmware" The vendor firmware uses the same layout and also ends at 0x1000000, so 16 MiB is what the product ships with rather than a smaller variant. Correct both values to describe the hardware. The result matches the other RTL9303 boards that use this Realtek reference layout on 16 MiB flash, notably the Vimin VM-S100-0800MS and the Sirivision SR-ST3408F, which both use <0x300000 0xd00000> and IMAGE_SIZE := 13312k. No released image has ever exceeded the truncated size (the current snapshot sysupgrade image is 5.6 MiB) and mtdsplit already derives rootfs_data from the truncated partition, so existing installations are unaffected and no compat version bump is needed. The bug is latent: check-size currently accepts images up to 29696k, more than twice what the flash can hold. Fixes: fbbc36c13672 ("realtek: add support for NicGiga S100-0800S-M") Signed-off-by: Greg Patrick <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24982 Signed-off-by: Jonas Jelonek <[email protected]>

• Jonas Jelonek(01 Sept 26)

  generic: 6.18: refresh patches Refresh patches to fix CI builds. The refresh was missed with the former change adding an additional backport patch. Refreshed with 'make target/linux/refresh V=99'. Fixes: 5322f1d79b2d ("generic: 6.18: mxl862xx enable assisted learning on CPU port") Signed-off-by: Jonas Jelonek <[email protected]>

• Rosen Penev(23 Aug 26)

  Revert "mediatek: filogic: fix GatoNetworks GDSP GPIOs exports" This reverts commit f1bf2d18392ef7b9f5f7bc6773055cfbddde371b. Now that the gpio-export driver was fixed, this need to be reverted for proper functionality. Signed-off-by: Rosen Penev <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24832 Signed-off-by: Jonas Jelonek <[email protected]>

• Rosen Penev(24 Jul 26)

  kernel: gpio-export: restore prior direction setup The GPIO direction was configured via the gpiod flags passed to devm_fwnode_gpiod_get_index(), i.e. at request time. Restore the prior behavior of requesting the GPIO as-is (GPIOD_ASIS) and setting the direction afterwards with gpiod_direction_output_raw() / gpiod_direction_input(). Note this deliberately does not restore the old skip-and-continue error handling: before 0ca7895 a failing request or direction setup was skipped with continue, leaving that GPIO unexported while the rest of the board still came up. Direction setup failures now abort the probe, consistent with the request failure handling introduced by 0ca7895. gpiod flags are also not used for the direction since legacy gpio_request_one() applied the initial output value raw (ignoring active-low), which gpiod_direction_output_raw() matches. Fixes: 0ca78951739a ("kernel: use fwnode for GPIO export driver") Signed-off-by: Rosen Penev <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24832 Signed-off-by: Jonas Jelonek <[email protected]>

• David Evans(19 Jul 26)

  realtek: add support for Zyxel GS1920-24 v1 The GS1920-24 v1 is the non-PoE, fanless sibling of the already supported GS1920-24HP v1 (ZyNOS firmware code AAOB vs. AAOC) and shares its board layout and flash map. Hardware: * SoC: Realtek RTL8392M * Flash: 16 MiB SPI NOR (Macronix MX25L12835F) * RAM: 128 MiB DDR3 * Ethernet: 24x 10/100/1000BASE-T (3x RTL8218B), 4x combo RJ45/SFP (RTL8214FC) * Hardware monitor: Analog Devices ADT7463C * LEDs: PWR, SYS, ALM, LOCATOR, per-port link/activity * Buttons: 1x reset (front) * UART: RS-232 level (not TTL) on header J2, DCE pinout (Tx pin 2, Rx pin 3, GND pin 5), 9600 8N1 * Power: 100-240 V AC, 50/60 Hz, 25.9 W max * No PoE, no fan MAC address: * Ethernet: factory MAC from the bootbase partition at offset 0x1fff8 through the factory_macaddr nvmem cell * ethernet0 is the label MAC device; 02_network uses this address for the LAN/bridge without assigning individual per-port MAC addresses The hardware monitor at I2C address 0x2e was identified on hardware as an ADT7463C from company ID 0x41 and VERSTEP 0x6a. The GS1920-24HP v1 uses an ADT7468, while the v2 uses an lm85-family hardware monitor at the same address. All GS1920-24 variants use hardware monitors supported by kmod-hwmon-lm85. The shared GS1920 device recipe therefore supplies that package, while the GS1920-24HP-specific recipe additionally supplies the PSE driver. Installation: 1. Connect to the console. Optionally switch BootBase to 115200 baud with ATBA5 (and reconnect at that rate). 2. Load an initramfs image into RAM: ATUP80100000, send the image via XMODEM, then ATGO80100000. 3. Copy loader.bin and the sysupgrade image to /tmp on the running initramfs system. 4. Flash both: mtd write /tmp/loader.bin loader mtd write /tmp/*-squashfs-sysupgrade.bin firmware 5. Reboot. The SFP side of the combo ports is untested (no modules available); the copper side of all 28 ports works. Tested on hardware: Flash installation and runtime operation verified. Signed-off-by: David Evans <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24962 Signed-off-by: Jonas Jelonek <[email protected]>

• David Evans(19 Jul 26)

  realtek: factor GS1920-24 common support Split the GS1920-24 device tree description into common hardware, RTL8392 v1-specific hardware and GS1920-24HP-specific PoE parts. Move the PSE controller node and per-PHY pses references from the GS1920-24HP common dtsi into an HP-specific overlay, leaving a PoE-free rtl839x_zyxel_gs1920-24-common.dtsi. This allows the non-PoE GS1920-24 v1 to share the common hardware without inheriting dangling PSE references, which would otherwise defer PHY probing. Keep the shared i2c4 bus in the common dtsi because it also carries the board hardware monitor; only the PSE controller is HP-specific. The GS1920-24 v1 and GS1920-24HP v1 also share RTL8392-specific board details, including memory size, console settings, flash layout and combo-port configuration. Factor these into a separate rtl8392_zyxel_gs1920-24-v1-common.dtsi. Likewise split the image recipe into GS1920 family-common and GS1920-24HP-specific parts. Keep kmod-hwmon-lm85 in the common recipe and leave the PSE driver HP-specific. No functional change is intended for the existing GS1920-24HP devices. The generated GS1920-24HP v1 and v2 DTBs are byte-identical before and after this commit. Signed-off-by: David Evans <[email protected]> Link: https://github.com/openwrt/openwrt/pull/24962 Signed-off-by: Jonas Jelonek <[email protected]>

• Edoardo Pinci(24 Aug 26)

  generic: 6.18: mxl862xx enable assisted learning on CPU port The MxL862xx driver enables FDB isolation but does not enable assisted learning on the CPU port. Consequently, MAC addresses learned through a physical switch port are not updated in hardware when the corresponding station moves to a foreign bridge port, such as a Wi-Fi interface. The stale hardware FDB entry continues directing return traffic toward the original physical port. Traffic entering that same port is then filtered instead of being forwarded to the CPU and software bridge. This causes downstream unicast traffic, including DHCP OFFER and ACK packets, to disappear after a client roams to a local wireless interface. The client eventually considers the connection unusable and disconnects. Enable assisted CPU-port learning so DSA installs foreign bridge FDB entries on the CPU port. This keeps the hardware FDB synchronized with the software bridge and allows return traffic to reach locally attached Wi-Fi clients after roaming. Tested on a BPI R4 PRO with a MxL862xx switch and a BE14000 WiFi interface. - Without patch, wired uplink on lan6 port (mxl path) Wifi clients connect but roam away not getting DHCP offers - Without patch, wired uplink on wan port (no mxl path) Wifi clients connect and roam successfully - With this patch, uplink on lan6 (mxl path) Wifi clients connect and roam successfully Fixes: 340bdf984613 ("net: dsa: mxl862xx: implement bridge offloading") Signed-off-by: Edoardo Pinci <[email protected]> Link: https://patch.msgid.link/DU0P251MB069949C6DEB4D1D51F31FE87C4A02@DU0P251MB0699.EURP251.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski <[email protected]>