ath79: fix u-boot-env nvmem-layout on enterasys,ws-ap3705i
The u-boot-env0 partition on this board stores a redundant U-Boot
environment (4-byte CRC32 + 1-byte flag + data), with the flag byte
differing between the u-boot-env0/u-boot-env1 copies (0x00 vs 0x01).
The actual environment size used by U-Boot for the CRC calculation is
0x1000 bytes, not the full 0x10000 byte partition.
The DTS declared this as the plain, non-redundant "u-boot,env" layout
with no env-size, so the kernel's u-boot-env nvmem-layout driver
miscomputes the CRC and fails to probe:
u-boot-env-layout ...nvmem-layout: Invalid calculated CRC32: 0xbc490a68 (expected: 0xfae56b95)
u-boot-env-layout ...nvmem-layout: probe with driver u-boot-env-layout failed with error -22
Because the probe fails, the macaddr_uboot_ethaddr nvmem cell is never
created, so eth0's nvmem-cells reference never resolves and the
ag71xx-legacy platform device is stuck in "deferred probe pending"
forever - the device boots with no functioning Ethernet interface at
all.
Switch to "u-boot,env-redundant-count" (matching the redundant-env
layout already used on other boards from this vendor lineage, e.g.
qca9557_extreme-networks_ws-ap3805i.dts) and set env-size to the
verified 0x1000, which fixes CRC validation and lets eth0 probe
successfully.
Verified on real hardware: before the fix, eth0 never comes up
(confirmed against the official 25.12.5 release, matching CRC values
exactly); after the fix, eth0 links up normally and dmesg is free of
any CRC/nvmem-layout errors.
Jonas Jelonek [Tue, 14 Jul 2026 13:16:42 +0000 (13:16 +0000)]
realtek: pcs: rtl930x: gate WDIG 10G-mode bit on real baud rate
This bit was set unconditionally for any 10G-capable SerDes regardless
of hw_mode, including SGMII/1000BASEX/2500BASEX running on 10G-capable
silicon. The vendor SDK's dal_longan_construct_mac_default_10gmedia_fiber
gates it on the port's declared protocol class instead, applying it to
PHY-attached XSGMII/USXGMII as well as genuine fiber - the "medium to
fiber" naming doesn't match its actual condition.
Gate on speed == RTPCS_SDS_PLL_SPD_10000 instead, matching the real
10G-class protocol family, and actively clear it for 1G/2.5G modes so a
prior 10G-class configuration doesn't leave it stuck across a runtime
downshift. 0 also matches this register's confirmed hardware reset
default on an unconfigured SerDes.
Jonas Jelonek [Fri, 10 Jul 2026 13:38:15 +0000 (13:38 +0000)]
realtek: pcs: rtl930x: gate TX tuning on attachment and baud rate
TX amp/pre-emphasis tuning depends on the SerDes' real baud rate class
rather than hw_mode, so key config_attachment's dispatch on that instead.
At 1G/2.5G, attachment doesn't change meaningful: even a non-adaptive
fiber receiver needs little compensation on a short trace, so
PHY-attached and fiber links already use the same config there. At 10G,
real channel loss is high enough that it matters: PHY-attached links
equalize on the PHY's own far-end receiver and need less amp drive,
while genuine fiber/DAC links, which have no adaptive receiver
downstream, need the full config. Real DAC-vs-fiber detection doesn't
exist yet, so both of those still share one config for now.
Make use of the PLL speed enum for now, though it is a bit blurry and
may not represent the real baud rate in some cases, e.g. QSGMII (1.25G
PLL with multiplier -> 5G).
Jonas Jelonek [Fri, 10 Jul 2026 09:13:40 +0000 (09:13 +0000)]
realtek: pcs: rtl930x: refactor TX config
Replace the on-stack, hardcoded pre/main/post-amp locals with static
const rtpcs_sds_tx_config data, one struct per speed class (1g, 2g5,
10g), instead of duplicating the same literals inline on every call.
Move the decision logic about which values are applied to the
config_media function. The tx_config should only be about what is set,
decision logic is handled one layer above. This also prepares further
refactoring.
Jonas Jelonek [Mon, 13 Jul 2026 10:50:21 +0000 (10:50 +0000)]
realtek: pcs: rtl93xx: commit attachment only after successful config
sds->attachment was written right after selection, before
config_attachment() ran, so a failed config call would leave it
reflecting a value that was never actually applied to hardware. Move
the assignment after the call succeeds, matching how sds->hw_mode is
only committed after set_hw_mode() succeeds.
Jonas Jelonek [Fri, 10 Jul 2026 13:53:01 +0000 (13:53 +0000)]
realtek: pcs: rtl93xx: rename media to attachment
"media" doesn't fit well once PHY sits alongside FIBER/DAC_SHORT/
DAC_LONG as a value: a PHY isn't a transmission medium, whereas what
actually matters here is what electrically terminates the SerDes lane
on the other end. Rename the enum, struct field, ops vtable member,
and both variants' config functions accordingly. Calling it 'attachment'
better fits what it actually is, doesn't confuse with the variants and
also fits to the PMA (Physical Medium Attachment) sublayer that lives
below PCS.
Jonas Jelonek [Fri, 10 Jul 2026 13:45:43 +0000 (13:45 +0000)]
realtek: pcs: rtl93xx: rename MEDIA_PCB to MEDIA_PHY
Every SerDes lane runs over some PCB trace before reaching the port,
even fiber/DAC ones, so PCB doesn't describe what actually
distinguishes this case: the SerDes terminates directly into a PHY
chip rather than a fiber module or DAC cable.
Jonas Jelonek [Fri, 10 Jul 2026 13:36:19 +0000 (13:36 +0000)]
realtek: pcs: rtl930x: classify SGMII as PHY-attached media
SGMII always terminates in a PHY, whether on-board or embedded in an
SFP copper module, so it belongs with QSGMII/XSGMII/USXGMII rather
than the direct fiber/DAC modes. The PHY equalizes on its own far-end
receiver in either case, so no media-dependent TX tuning is needed.
Jonas Jelonek [Mon, 13 Jul 2026 12:17:50 +0000 (12:17 +0000)]
realtek: pcs: rtl930x: only apply TX config for 10G SerDes
So far, there was only a misleading and confusing gate to avoid applying
the TX config to SerDes which do not need it or where it even breaks
some modes. This is achieved by not applying any configuration for
QSGMII mode. While this fits the real-world cases we know so far where
QSGMII is only used on SerDes 0/1 but never on others, it implicates
that this is true too for QSGMII on 10G SerDes. Looking at the SDK, this
assumption doesn't hold.
To fix this, drop out of config_media in case a non-10G SerDes is
delivered. The SDK does the same in various ways, ending up with the
config just being applied for SerDes 2 - 9.
Jonas Jelonek [Fri, 10 Jul 2026 08:56:57 +0000 (08:56 +0000)]
realtek: pcs: rtl930x: use cmu_page getter for tx_config
Derive the CMU page from rtpcs_93xx_sds_get_cmu_page() instead of
hardcoding it per hw_mode case. Also change the function to return
int and propagate errors instead of silently doing nothing.
Jonas Jelonek [Fri, 10 Jul 2026 08:48:48 +0000 (08:48 +0000)]
realtek: pcs: rtl93xx: make cmu_page getter generic
Rename rtpcs_931x_sds_cmu_page_get() to rtpcs_93xx_sds_get_cmu_page()
and move it next to the other 93xx-shared helpers, so RTL930X can
reuse it instead of duplicating the same hw_mode-to-CMU-page switch.
Also fix the wrong -ENOTSUPP return to -EOPNOTSUPP.
Jonas Jelonek [Sun, 3 May 2026 22:13:44 +0000 (22:13 +0000)]
realtek: use realtek-pse-mcu kernel driver for PoE on XMG1915-10EP
Instead of relying on the userspace implementation, make this device the
first user of the new realtek-pse kernel driver (kmod-pse-realtek-mcu-uart)
based on the PSE-PD framework to interface PoE functionality of that
switch. Control of PoE functionality happens via ethtool / netifd now.
Drop selecting realtek-poe for this device.
This doesn't include any support for PoE-related LEDs.
Jonas Jelonek [Wed, 1 Jul 2026 10:47:27 +0000 (10:47 +0000)]
realtek: pse: add patch for sysfs detection control
Add a patch which modifies the Realtek PSE MCU driver backport to add a
sysfs control to control detection mode per port. Some older,
bad-designed devices aren't detected properly in standard mode on some
switches, though vendor firmware powers them properly. Testing shows
that enabling the detection of legacy PDs by allowing wider resistance,
more input capacitance and using a wider detection window, solves this
issue.
The legacy detection can be activated by writing 1 to
portN/detection_legacy in the device's sysfs, e.g.
Jonas Jelonek [Sun, 3 May 2026 20:44:35 +0000 (20:44 +0000)]
realtek: add Realtek PSE MCU driver
Add pending patches which add a PSE driver for the PSE setup found on
most of Realtek-based switches. An MCU with a Realtek-defined firmware
and protocol fronts one or more PSE chips (from Realtek or Broadcom) as
a management controller.
The driver provides both I2C/SMBus and UART communication, which varies
among our supported switches. There is no need for complicated userspace
handling anymore, the PSE setup is defined in the device tree and
interfaced in userspace via ethtool, netlink and netifd support.
Those patches have progressed far enough upstream, the bindings are
reviewed. Thus, we can keep this intermediate version downstream to open
it up earlier for usage. Only little changes are expected til the final
version lands.
Jonas Jelonek [Sun, 3 May 2026 20:43:57 +0000 (20:43 +0000)]
generic: pse-pd: add patches for module-based PSE drivers
Add a backport patch and pending patches needed by upcoming PSE drivers
which are built as modules and probed after the MAC/PHY.
The net effect for module-built PSE controllers: attachment to PHYs
happens via the lifecycle notifier rather than via probe-time
-EPROBE_DEFER coupling, so the MDIO/DSA probe no longer sees any
PSE-originated -EPROBE_DEFER and the probe-retry storm is gone.
airoha: configure PCIe 2-lanes mode for eMMC EAGLE RFB board
The EAGLE PCIe WiFi card require PCIe0 to be in 2-lanes mode to correctly
work. Add the missing property to enable this mode and restore correctly
functionality of the WiFi card.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
airoha: replace PCIe x2-mode patch with new pending version
The current x2-mode patch is mostly an hack ported from Airoha SDK. Replace
with in favor of a new version posted upstream that better implement
handling of reset and configuring x2-mode. This now use the standard
num-lanes property and dedicated PERSTOUT resets exported by the clk
driver.
All the DTS that used x2-mode are updated.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Robert Marko [Mon, 13 Jul 2026 09:07:26 +0000 (11:07 +0200)]
qualcommax: pin EDMA processing to dedicated CPUs
IPQ60xx and IPQ807x use threaded NAPI for EDMA. The NAPI threads
inherit CPU0 affinity, and running both there can eventually starve the
RX fill ring under sustained traffic.
Add an IPQ60xx smp_affinity service and extend the existing IPQ807x
service to discover the EDMA IRQs and NAPI IDs at runtime. Place RX on
CPU1 and TX on CPU2. Retry EDMA setup asynchronously because its NAPI
threads may appear after the init service runs.
Provide the same UCI enable and logging controls on both subtargets.
IPQ50xx uses a different Ethernet driver and is left unchanged.
Robert Marko [Mon, 13 Jul 2026 08:39:43 +0000 (10:39 +0200)]
qualcommax: qca-edma: enable threaded NAPI by default
Run the EDMA RX and TX NAPI poll loops in dedicated kernel threads by
default. This allows the threads and their interrupts to be placed on
separate CPUs and avoids overloading a single softirq context.
If thread creation fails, dev_set_threaded() leaves NAPI in softirq mode
and the driver reports the failure.
A malformed RX preheader can occur repeatedly after the descriptor ring
overruns. Rate-limit the warning to prevent excessive console output
from making the receive stall worse.
Decode the little-endian preheader metadata before printing it and use
consistent hexadecimal formatting.
qualcommax: ipq8072: assign NVMEM MAC addresses for Linksys MX5300
While the base NVMEM cell (hw_mac_addr) is already defined in the device tree, it was not being utilized by the actual interfaces.
This patch completes the kernel-level MAC assignment by:
1. Correcting the label-mac-device alias to point to the WAN port (&swport5), ensuring the system reports the sticker MAC address correctly.
2. Assigning the base MAC address (offset 0) to the WAN port (&swport5).
3. Assigning the base MAC address (offset 1) to the LAN ports (&swport1 - &swport4).
4. Configuring the proper NVMEM cell references for the PCIe-attached QCA9984 radio (offset 2) and the built-in ATH11K radio (offset 3).
This eliminates the need for post-boot MAC address manipulation and ensures robust, predictable interface initialization.
George Moussalem [Mon, 13 Jul 2026 05:48:04 +0000 (09:48 +0400)]
qualcommax: ipq50xx: enable in-band-status for MXL GPY115C PHY on Linksys MX6200
The MXL GPY115C PHY requires in-band-status to be set properly detect
link status and communicate phy capabilities. So enable in-band-status
in the Linksys MX6200 device tree.
ramips: ethernet: ralink: refine DSA tag offload handling
DSA copies the driver features to slave device, including offload
capabilities. Once a packet is sent through a DSA slave interface,
according to its features, the kernel does not calculate checksums,
expecting that the HW will fill the gaps. DSA adds the defined DSA
tag and sends the tagged packet through the master device.
Ethertype DSA tags expect the driver to calculate checksum based on the
csum_start/csum_offset. However, mtk_soc_eth does not use that info.
It checks the network header and decides if the HW can manage that
packet, unaware that mac layer now contains an extra DSA tag. When
that tag is the Mediatek CPU tag, offload will work as expected.
When it is an incompatible DSA tag or if DSA is stacking two incompatible
DSA tags, the driver will still count on the HW offload. In this case,
packets go to the network with an incorrect checksum.
Before this change, tag_ops->proto == DSA_TAG_PROTO_MTK was used,
which disabled offload for every non-Mediatek tag, including the
RTL8367S switch's RTL8_4 tag that this fix specifically targets.
Replace the hardcoded whitelist with a blacklist scoped to the
RTL8367S: only disable offload for DSA_TAG_PROTO_RTL8_4. The RTL8_4T
(the trailing-tag variant) is left untouched because its rtl8_4t tagger
already checksums the frame in software before appending the tag.
Tags for other DSA-capable switches are left untouched by this fix
and are not claimed to be offload-safe.
Fixes: 3c0a73b4d202 ("ramips: ethernet: ralink: fix offload with diff dsa tag") Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com> Link: https://github.com/openwrt/openwrt/pull/24064 Signed-off-by: Robert Marko <robimarko@gmail.com>
mediatek: ethernet: fix offload with incompatible dsa tag
DSA copies the driver features to slave device, including offload
capabilities. Once a packet is sent through a DSA slave interface,
according to its features, the kernel does not calculate checksums,
expecting that the HW will fill the gaps. DSA adds the defined DSA
tag and sends the tagged packet through the master device.
Ethertype DSA tags expect the driver to calculate checksum based on the
csum_start/csum_offset. However, mtk_eth_soc does not use that info.
mtk_eth_soc checks the network header and decides if the HW can manage
that packet, unaware that MAC layer now contains an extra DSA tag. When
that tag is the Mediatek CPU tag, offload will work as expected.
When it is an incompatible DSA tag or if DSA is stacking two incompatible
DSA tags, the driver will still count on the HW offload. In this case,
packets are sent to the network with an incorrect checksum.
This patch adds an extra check that disables offloading only for the
RTL8367S switch's RTL8_4 tag, which is known to break MTK checksum
offload. The RTL8_4T (the trailing-tag variant) is not affected because
its rtl8_4t tagger already checksums the frame in software before appending
the tag, so ip_summed is no longer CHECKSUM_PARTIAL by the time this driver
sees it.
This approach avoids an overly conservative whitelist which would
disable offload for every non-Mediatek tag, regardless of whether
that tag is actually incompatible with MTK checksum offload.
Tags for other DSA-capable switches are left untouched by this fix
and are not claimed to be offload-safe.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Schneider Azima <Schneider-Azima12@protonmail.com> Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com> Link: https://github.com/openwrt/openwrt/pull/23996 Signed-off-by: Robert Marko <robimarko@gmail.com>
Michael Pratt [Sat, 4 Jul 2026 07:21:49 +0000 (03:21 -0400)]
tools: gnulib: rename macro file for cond module
It was reported that cond.m4 in gnulib is a name clash with
cond.m4 provided by Automake, where they are for completely
different purposes instead of different versions of the same macros.
A quick survey of all the macro files in the build directory reveals that
this is the only case where the gnulib copy is signficantly smaller
than the rest of the copies of the same macro name
distributed in the rest of the build system,
and the only one that name clashes with Automake.
A previous fix added a prefix to all macros from gnulib,
but the name must match how it is described in the respective modules files
as a functional requirement to build certain tools for certain (older) hosts,
so patch the problematic module instead of renaming all macros from gnulib.
Ref: c820f097e0be ("tools: gnulib: install .m4 file with gl_ prefix")
Ref: 78a8cfb57772 ("tools: gnulib: fix broken install of .m4 files") Reported-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/24136 Signed-off-by: Robert Marko <robimarko@gmail.com>
Shiji Yang [Tue, 27 May 2025 16:32:56 +0000 (00:32 +0800)]
lantiq: use gpiod API for PCIe GPIO reset
This is the recommended way for the OF based platform. According to
the original patch, set GPIO to low level to assert the reset, set
GPIO to high level to deassert. Hence, adjust the dts GPIO polarity
to active-low.
John Crispin [Wed, 18 Feb 2026 16:35:15 +0000 (17:35 +0100)]
qualcommax: replace NSS-DP DTSI with PPE DTSI
Add DTSI files defining EDMA, PPE, and UNIPHY nodes for the new PPE
driver bindings on IPQ5018, IPQ6018 and IPQ8074 platforms.
IPQ5018 requires a patch for UNIPHY node as its cmn PLL node is upstream.
These replace the existing NSS-DP ones.
Signed-off-by: John Crispin <john@phrozen.org>
[IPQ5018] Signed-off-by: George Moussalem <george.moussalem@outlook.com>
[IPQ6018 and IPQ8074] Link: https://github.com/openwrt/openwrt/pull/22381 Signed-off-by: Robert Marko <robimarko@gmail.com>
Add IPQ5018 DWMAC driver. IP version of this Synopsys DWMAC is 3.7.
This Qualcomm IPQ5018 specific MAC implementation supports link speeds
of 10HD/FD, 100HD/FD, 1,000HD/FD, and 2500FD and SGMII and 2500BASEX
interface modes.
The driver supports the MAC be attached directly to a PHY or via an
optional PCS to a switch or PHY.
John Crispin [Wed, 11 Mar 2026 18:05:12 +0000 (19:05 +0100)]
qualcommax: add EDMA driver
EDMA dataplane ethernet driver for Qualcomm IPQ platforms.
Signed-off-by: John Crispin <john@phrozen.org>
[ rework Makefile for external repository, dependency ] Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
[ rework for in-tree ] Link: https://github.com/openwrt/openwrt/pull/22381 Signed-off-by: Robert Marko <robimarko@gmail.com>
John Crispin [Wed, 11 Mar 2026 18:04:53 +0000 (19:04 +0100)]
qualcommax: add PPE driver
PPE switch driver for Qualcomm IPQ platforms, depends on EDMA and
UNIPHY PCS.
Signed-off-by: John Crispin <john@phrozen.org>
[ rework Makefile for external repository, dependency ] Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
[ bring PPE in-tree ] Link: https://github.com/openwrt/openwrt/pull/22381 Signed-off-by: Robert Marko <robimarko@gmail.com>
John Crispin [Wed, 11 Mar 2026 18:04:30 +0000 (19:04 +0100)]
qualcommax: add UNIPHY PCS driver
PCS driver for UNIPHY SerDes blocks on Qualcomm IPQ platforms.
Signed-off-by: John Crispin <john@phrozen.org>
[ rework Makefile for external repository, dependency ] Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
[ make it in-tree under qualcommax ] Link: https://github.com/openwrt/openwrt/pull/22381 Signed-off-by: Robert Marko <robimarko@gmail.com>
Migration to OpenWrt:
- Download the RSA signed intermediate firmware:
`openwrt-ramips-mt76x8-cudy_lt500-outdoor-v1-squashfs-flash.bin`
- Connect computer to LAN and flash the intermediate firmware via OEM web interface
- OpenWrt is now accessible via 192.168.1.1
Revert back to OEM firmware:
- Press the reset button while powering on the device
- Connect the LAN port to the PC
- Open 192.168.1.1 in a browser and use the wizard to upload and flash OEM firmware image
- When recovery process is done, OEM firmware is accessible via 192.168.10.1 again
Shine [Sun, 31 May 2026 18:33:57 +0000 (20:33 +0200)]
scripts: dhcp: option to override preferred Client ID per interface
Using UUID-based client IDs for DHCPv4/DHCPv6 with no option of falling
back to hardware IDs (ie. MAC-address or DUID-LL) resp. none at all (IPv4),
is causing regressions in some setups.
Introduce a new setting to override the preferred client ID to be used for
DHCPv4/DHCPv6 on a per-interface basis:
- "auto" (default if empty or not present) uses any explicitly defined
client ID, or falls back to the global DUID and finally to the DUID-LL
resp. MAC address (ie. identical to before this commit).
- "global" uses the global default DUID, if configured, for DHCPv4 and
DHCPv6 requests, even if a client ID is explicitly specified for the i/f
- "hardware" will not pass a client ID to udhcpc/odhcp6c, even if a global
default DUID is configured or an explicit client ID specified, resulting
in the i/f MAC address resp. type 3 DUID(-LL) to be used
- "none" (IPv4 only) will not add an option tag 61 to DHCPv4 requests at
all.
struct gpio_keys_button has an unsigned int for its irq field. A signed
one is needed for fwnode_irq_get. Handle it before passing it to the
button member.
Fixes: 79b9a36959ea ("gpio-button-hotplug: use device and fwnode") Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24174 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Changes:
* removed upstreamed patches,
* refresh patches,
* add en7523/an7581/an7583 pinctrl support
* add basic PCS support for an7583
* add an7583 specific mdio bus support
The partition layout wasn't tested properly on the device and has major
issues, possibly soft-bricking the device on first boot. Thus, the
installation procedure in the commit message is faulty. Revert for now.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Fil Dunsky [Fri, 9 Jan 2026 17:16:30 +0000 (20:16 +0300)]
mediatek: add support for Hiveton H5000M
Hardware specification:
SoC: MediaTek MT7987A
Flash: 8GB eMMC
RAM: 1GB DDR4
Ethernet: 2x 2.5GbE (RTL8221B PHY + Internal PHY)
WiFi: MediaTek MT7992 / 2+3 antenna variant
Interface: M.2 USB for 5G module
LED: Power (hw-controlled), 2.5G WAN (user-definable),
5G Module (hw-controlled), LED-3 (user-definable),
LED-4 (user-definable)
Button: Reset, WPS
Power: USB Type-C PD
Other: PWM Fan control
MAC address assignment is unconventional: the board has no Factory
partition with pre-programmed MACs. Instead, all addresses are
derived from the eMMC CID at runtime:
LAN : macaddr_generate_from_mmc_cid mmcblk0
WAN : LAN + 1 (label_mac)
phy0: LAN + 2
phy1: LAN + 3
This matches the vendor firmware behaviour and ensures stable,
unique addresses across reboots without a dedicated EEPROM region
for MACs.
Flash instructions:
Factory `mmcblk0p2` partition is empty,
stock ImmortalWrt-798x-mt799x-6.6-mtwifi from PadavanOnly firmware
uses `MT7991_MT7976_EEPROM_BE5040_iPAiLNA.bin`.
Flashing this eeprom before flashing OpenWrt will make OpenWrt read eeprom:
```
dd if=/lib/firmware/MT7991_MT7976_EEPROM_BE5040_iPAiLNA.bin of=/dev/mmcblk0p2 bs=1 count=7680
sync
```
But it will have wifi issues for now. It's better to use OpenWrt fallback eeprom for now.
Power off the device.
Press and hold the Reset button.
Power on the device while keeping the Reset button pressed.
Wait for the device to enter U-Boot recovery mode.
Connect to the device via Ethernet (default IP: 192.168.1.1).
Set your PC's IP to 192.168.1.x (e.g., 192.168.1.100).
Open a web browser and navigate to http://192.168.1.1
Upload and flash the OpenWrt firmware
Wait for the flashing process to complete and the device to reboot.
It's used in probe to be a generic way to iterate over the children.
Confusingly, device_for_each_child_node_scoped internally calls the
available loop despite not mentioning it.
Rosen Penev [Thu, 25 Jun 2026 02:00:29 +0000 (19:00 -0700)]
kernel: replace strcpy/strcat with strscpy/strlcat
Replace deprecated strcpy/strcat calls with strscpy/strlcat for
bounds-checked string operations in swconfig_leds, clk-rtl83xx,
and UML pseudo-random MAC patch.
Jonas Jelonek [Mon, 6 Jul 2026 15:15:59 +0000 (15:15 +0000)]
realtek: add support for Ubiquiti UniFi USW Pro Max 24 PoE
Add support for RTL9302B-based Ubiquiti UniFi USW Pro Max 24 PoE switch
with 16x GbE and 8x 2.5G RJ45 ports, 2x SFP+, and a front display.
Hardware
========
- RTL9302B switch SoC
- 512 MiB RAM
- 32 MiB SPI-NOR flash
- 16x 100M/1G RJ45 ports via 2x RTL8218E
- 8x 100M/1G/2.5G RJ45 ports via 2x RTL8224
- PoE:
- 400W total budget
- 8x 802.3at, 32W per port (ports 1-8)
- 16x 802.3bt, 60W per port (ports 9-24)
- 2x SFP+ ports
- Buttons: 1x Reset
- LEDs: RGBW LED per port (Etherlighting)
- Front touch display via USB ACM (see below)
- Console: TTL 3.3V, 115200 8N1 (internal pin header close to SoC;
layout front to back: VCC RX TX GND)
- Etherlighting feature (lighting patterns and color control)
- Vendor firmware: U-Boot + LEDE-based Ubiquiti OS
MAC address
===========
Single MAC address in EEPROM partition, applied to all ports.
Front touch display
===================
The unit has a touch-capable front display, driven by a dedicated
STM32-based MCU. Unlike other Ubiquiti switches where the MCU is
connected to the SoC via UART directly, here it is exposed as a USB
CDC-ACM serial device through an on-board Genesys Logic GL850G USB hub.
The MCU runs Ubiquiti's LCM firmware and exposes a high-level JSON
protocol (page selection, button-press events, etc.); arbitrary
pixel-level control is not possible without replacing the MCU firmware.
Display support therefore depends on both USB host support and a driver
for the LCM protocol, neither of which is currently available.
Known issues
============
- PoE not available, depends on WIP Realtek PSE MCU driver
- Etherlighting not controllable, driver WIP. Port LEDs for link work
though. By default, the controller keeps the LEDs in a breathing
state, gated by the link state delivered by the Realtek SoC.
Disclaimer
==========
Stock firmware uses a dual-bank layout (kernel0/kernel1, ~15 MiB each).
OpenWrt replaces both banks with a single contiguous firmware partition.
Flashing OpenWrt overwrites both stock kernel slots; U-Boot remains
intact and can be used for recovery.
Installation
============
1. Enable SSH on the stock UniFi OS and log in with user account.
2. Copy the OpenWrt sysupgrade image to /tmp on the switch (e.g. via
scp).
3. Adjust IMG below to point at the copied file, then run the block as a
whole. It writes kernel0, splits into kernel1 if the image is larger
than that slot (otherwise invalidates kernel1 so U-Boot cannot pick
a stale bank), and reboots:
4. It is recommended to modify the bootcmd to speed up the boot and
prevent any issues due to the dual-boot selection. Since U-Boot by
default uses bootubnt which does a lot of (unneeded) RTK
initialization, quite some time passes until Linux is started.
Additionally, the U-Boot logic fiddles with some bits on flash which
causes JFFS2 errors in OpenWrt. While this doesn't seem to cause
issues yet, be defensive and set the bootcmd to:
bootm 0xb4150000
This directly boots the uImage from flash, without doing all the
initialization. OpenWrt is able to bootstrap the networking
completely on its own.
It does not matter which bank stock booted from when the dd block
runs: both banks are touched in the same pass (kernel0 written, kernel1
either written or invalidated). With kernel1 invalidated, U-Boot's
internal fallback kicks in and permanently switches to kernel0 on the
next boot, so the device stays on OpenWrt as long as kernel0 is
bootable.
Recovery
========
Since the installation procedure invalidates or partially overwrites
the second bank, recovery requires serial console access (see Hardware
above for pinout).
1. Interrupt U-Boot autoboot by spamming a key during early boot to
drop into the U-Boot prompt.
2. Bring up networking:
rtk network on
3. Transfer an OpenWrt initramfs image via TFTP and boot it:
4. From the running initramfs OpenWrt, do a sysupgrade to reflash
OpenWrt or whatever you want to recover. There is no need for the
complicated procedure from installation since OpenWrt sees the
firmware partition already as a whole.
Return to stock firmware
========================
There is no fully-supported revert path. The stock firmware blob is a
Ubiquiti UBNT archive (header + parts, see firmware-utils' fw.h) that
embeds a u-boot and a kernel0 uImage payload; only the latter is
relevant when writing back to the kernel partitions.
The snippet below extracts the kernel0 uImage from such a blob by
locating the uImage magic and using the size carried in the uImage
header itself, without parsing any UBNT framing. It is provided as a
best-effort starting point; verify the result before flashing,
otherwise you're on your own:
Once you have a clean uImage, write it to the kernel partition from
within OpenWrt. If you adjusted the bootcmd during installation, make
sure to restore it to the default "bootcmd=bootubnt". After a reboot,
Ubiquiti's firmware should boot.
Or, if you made backups of the flash before installation, just write
the backup back to flash.
Felix Fietkau [Wed, 8 Jul 2026 08:48:32 +0000 (10:48 +0200)]
netifd: update to Git HEAD (2026-07-08)
c0abf80df1c1 config: fix NULL pointer dereference when typed device creation fails 4a19d2568c0b device: migrate alias users when replacing a device e2f28e5ec0a8 interface: defer interface removal to avoid use-after-free 34760f2aec34 interface: fix alias handling when the parent interface does not exist 0bab70f05296 bridge: cancel the member retry timer on teardown and free a562a8eca41d bridge: fix memory leak of hotplug member vlan ranges 4c7b3f7caf88 proto-ext: clear the proto task kill flag when starting a new task 8a38aecd84de system-linux: include the priority when deleting ip rules 844c0fe78eed device: remove unused __devlock counter dbdf0d0e5830 system-linux: initialise FMR prefix lengths before parsing fb456b5e65df iprule: keep unchanged rules installed on reload 7d8f9900c273 vrf: sync changes with bonding.c/bridge.c f0db4101c1ea vrf: remove incorrect IPv6 disable on VRF ports 9dfea5b242b2 vrf: remove unused vrf_empty field 6f6bf8bec23b vrf: rename vrf_state_type to vrf_device_type 37c770a6b86d vrf: add license header 35171a157516 system-linux: fix system_vrf_addif retry loop 6cbcc107e984 bonding: cancel the port retry timer on teardown and free 787848926a19 extdev: fix invalid frees and unwind order on handler registration failure 2a8ed44dc613 interface-ip: fix address family check when removing offlink null-routes 576e1f3de154 interface-ip: preserve subnet route state when keeping an address 10f25df801c1 bridge: fix parsing of the stp_kernel option 3132f007ebf0 bonding: skip present toggle in bonding_free_port() when device is active 24950e564fff bonding: fix stale primary_port pointer after port enable failure 4c8374dc0f79 interface: fix zone string leak on config reload 65e96ba990b2 ubus: fix netns fd leak in netns_updown error path fa9ee5efd4b2 utils: fix out-of-bounds fallback in uci_get_validate_string 6ccbf71d7a97 utils: fix false positives and dead branch in check_pid_path 3ec503831ebd iprule: default src/dest masks to the host prefix length 9a520edc3be4 system-linux: implement the neighbour flush in system_if_clear_entries 62b6256bf95c system-linux: fix vxlan link creation with gbp disabled 6c0a837f10fc system-linux: fix rtnl socket desync when clearing kernel entries d1a0ceb71991 macvlan: fix NULL dereference when dumping a device without parent 937c3aa801af vlandev: fix NULL dereference when dumping a device without parent 89025924ba51 vlan: fix device chain lookup for names with a non-vlan separator c961d1e16814 vlan: fix rejection of maximum length vlan device names 1cbf89e3108c vlandev: fix type of vlan alias lookup result 08a4a7b33056 proto-ext: fix stuck state machine when the setup script fails to launch c8c8b79a5bcb proto-ext: queue restart requests while a script task is running 0c990ce2ca09 ubus: report failure from the interface restart method e6af4a5bf6f2 interface: fix undefined shift when computing the ip6hint mask 67f8107fb21c interface-ip: fix undefined shifts in prefix assignment arithmetic 903bd1c3daa5 interface-ip: fix out-of-bounds access in clear_if_addr for zero masks 56ffff895672 system-linux: fix ethtool feature block count bbc818a6527f system-linux: fix EINTR retry in read_string_file 9c2970832d8f system-linux: fix off-by-one in vxlan VNI validation c5b5d54ce2f9 bridge: validate the upper bound of hotplug vlan ranges 1595cd7b25da main: handle execvp failure on restart 24b2703171fe handler: guard against zero-length lines when parsing handler dumps c2b760fc7cc5 handler: free glob results in netifd_init_extdev_handlers 60e3243bdcd8 handler: reject negative parameter types in handler descriptions 274b1594e0ca interface-ip: tear down the ULA prefix on an invalid prefix length e692ec77d51b interface-ip: expire config routes with a valid option 684dc2d50902 device: fix error handling in device_create c02101330247 interface: fully clean up partially constructed interfaces on free 1db485d6a39c handler: clear parameter list pointers on parse failure 5694c49f964f system-linux: stop receive loops on netlink errors d108c504df4e system-linux: fix bogus master ifindex result for non-DSA devices d6f609170f1e system-linux: fix swapped rx/tx in negotiated pause reporting 8a19380586ef extdev: fix NULL pointer dereference when parsing stats params a1cc96488c02 extdev: fix memory leaks on device free d2085a59abbc extdev: fix bridge config leak on no-op reload 4d1a4ae487b6 ucode: close pipe read end in spawned child processes 6c407410259c config: validate bridge vlan port and alias attributes 8afd58bead2f bridge: fix pvid clearing leaking to other vlan members e8edb3f78652 bonding: fix port failure accounting in bonding_enable_port 6088f7b3b9d7 system-dummy: fix metric clobbering device name in route debug output
Felix Fietkau [Wed, 8 Jul 2026 08:48:27 +0000 (10:48 +0200)]
libubox: update to Git HEAD (2026-07-08)
e2fa9dcf67a8 uloop: fix use-after-free when cancelling interval timers 329d823294a0 uloop: keep signal handler installed while other watchers remain 3362b39a1c03 kvlist: fix use-after-free when updating an entry in place b33f74af02b2 list: define list_prev_entry used by list_for_each_entry_continue_reverse 65f62583c236 udebug: check hdr before dereferencing it in set_start_time 9d7fb82530b5 udebug: reject non-power-of-two ring metadata from a peer 2e0e7f0f4d38 udebug: verify shared-memory fd size before mapping dda814a9750a usock: retry poll() on EINTR in usock_wait_ready() 72e2b396bd9a ustream: reset byte and buffer counters when freeing buffers be161d0320da utils: guard cbuf_order against zero and one 08081477ad6c uloop: fix kevent() eventlist size argument in register_kevent 0c3eec553828 uloop: fix kqueue timer interval arithmetic a9ab90bd1d5d uloop: fix use-after-free in signal_consume when a callback deletes a watcher c08a4ab53129 uloop: fix use-after-free in uloop_handle_processes when a callback deletes a process 7677b7a4f3a4 vlist: pass the tree as comparator context in VLIST_TREE_INIT
Robert Marko [Mon, 6 Jul 2026 13:19:44 +0000 (15:19 +0200)]
mac80211: ath12k: fix regulatory range for wideband radios
Currently, trying to start a 5GHz radio on 8devices Kiwi will fail as
despite the phy listing the 5GHz channels in iw phy dump, no radio actually
claims the 5GHz range.
This is because driver assumes that if radio supports 6GHz then it cannot
be used for 5Ghz, this is however not correct for wideband radios.
So, similar to the 103-wifi-ath12k-fix-5GHz-operation-on-wideband-QCN.patch
patch ath12k_regd_update() so that 5Ghz range is listed as well.
Felix Fietkau [Tue, 7 Jul 2026 08:31:42 +0000 (10:31 +0200)]
ucode: fix two compiler issues
- When working with deeply nested imports, compile errors led to long
error messages or complete hangs by compiling the same module over
and over again.
- Fix for a function expression scope issue.
OrbisAI Security [Fri, 15 May 2026 01:25:24 +0000 (06:55 +0530)]
ixp4xx-microcode: use snprintf in IxNpeMicrocode.h
Replace sprintf() calls with snprintf() to bound writes into the
fixed-size filename[] and slnk[] stack buffers. While the current
inputs are hash-pinned firmware images, snprintf provides defense
in depth against buffer overflows if the format string output ever
exceeds buffer capacity.
Ryan Leung [Wed, 6 May 2026 11:31:01 +0000 (21:31 +1000)]
scripts: feeds: don't refresh .config upon update
Feeds update does not make updated packages available to compile; they must be installed.
Despite this, update refreshes the .config, deleting selections in the .config which have not been
installed yet. The deleted selections are not restored with `./scripts/feeds install` nor with
`make defconfig` because these steps cannot conjure up already deleted selections.
Change update to not modify the .config and leave it to `./scripts/feeds install -d <y|m|n>` or
`make defconfig` or other *config options.
Joshua Covington [Fri, 26 Jun 2026 12:22:45 +0000 (12:22 +0000)]
kernel: add Kconfig options for ARM64_BRBE and THP enhancements on 6.18
Introduce new kernel configuration options for memory management
and hardware-profiling features:
- KERNEL_ARM64_BRBE: Enables support for the Branch Record Buffer
Extension (FEAT_BRBE) on ARM64 architectures when perf events are active.
- KERNEL_PERSISTENT_HUGE_ZERO_FOLIO: Allows allocating a PMD-sized
folio for zeroing, optimizing Transparent Hugepage (THP) allocation
performance.
- KERNEL_NO_PAGE_MAPCOUNT: Adds experimental support for bypassing
per-page mapcount tracking to reduce memory accounting overhead under THP.
These options map directly to their respective kernel options and are
applicable on 6.18 and later.
Joshua Covington [Mon, 22 Jun 2026 21:56:35 +0000 (21:56 +0000)]
bcm27xx-gpu-fw: remove dependency for bcm2712
bcm2712 uses a dedicated eeprom chip with closed-source blobs
provided via rpi-eeprom which is part of the bcm27xx-utils.
No need to install the old firmware files on this target.
Joshua Covington [Mon, 22 Jun 2026 21:55:36 +0000 (21:55 +0000)]
bcm27xx: do not install bcm27xx-gpu-fw on bcm2712
bcm2712 uses a dedicated eeprom chip with closed-source blobs
provided via rpi-eeprom which is part of the bcm27xx-utils.
No need to install the old firmware files on this target.
This is triggered by CONFIG_ALL_KMODS=y. The old 32-bit Raspberry Pi
subtargets do not normally select this driver for runtime use, but all-kmods
forces the kmod package to be built anyway. On 32-bit ARM, raw 64-bit
division in a module can cause GCC to emit the ARM EABI helper
__aeabi_uldivmod, which is not available as a kernel module symbol.
The failing reference comes from i2c-designware-master.c, where clock_calc()
uses raw u64 division for SCL timing calculations (introduced with commit 3805d13c3ead21494f7d00aa44f10e3656363d4c in rpi-6.18.y / "i2c: designware:
Support non-standard bus speeds"). That is a kernel-side portability issue,
but these old bcm27xx subtargets do not use DesignWare I2C hardware. They
use the Broadcom I2C controller instead.
The failure is emitted for i2c-designware-core.ko, so guard the hidden core
package itself rather than only guarding the platform or PCI frontend package.
This prevents CONFIG_ALL_KMODS from selecting the failing core module directly
on the affected 32-bit bcm27xx subtargets.
DesignWare I2C is relevant for newer Raspberry Pi 5 / RP1 based systems, so
keep it available for bcm2712.
A similar issue was reported by NixOS for Raspberry Pi ARM builds, where
i2c-designware-core.ko failed with the same unresolved __aeabi_uldivmod symbol.
Their workaround was to disable the DesignWare I2C symbols for older Raspberry
Pi targets that do not need them. Link: https://github.com/NixOS/nixpkgs/issues/464515
Until the underlying ARM32 kernel-side issue is fixed, avoid building
the DesignWare core package on bcm2708, bcm2709 and bcm2710.
Joshua Covington [Mon, 22 Jun 2026 21:52:08 +0000 (21:52 +0000)]
bcm27xx: adapt RP1 and media kernel modules for 6.18
kmod-rp1:
kmod-rp1-mailbox:
RP1 is the I/O controller on the BCM2712 SoC. The RP1 drivers are compiled
directly into the kernel, granting access to peripherals at early boot.
Consequently, separate packages are no longer required for 6.18 on bcm2712.
kmod-rp1-cfe:
Adapt kmod-rp1-cfe packaging for Linux 6.18 kernel changes,
by updating module paths and dependencies for the upstream driver.
kmod-rp1-cfe-downstream:
kmod-rp1-hevc-dec:
Package downstream CFE and HEVC decoder drivers for bcm2712 on 6.18.
kmod-vc4:
Add a conditional dependency on kmod-drm-exec for 6.18 builds
and move DRM helper modules to their corresponding helper kmods.
projects / thirdparty / openwrt.git / log
