realtek: eth: adapt interrupt handling for fragments
The existing interrupt handling of the ethernet driver worked
well until the driver implemented receive fragment handling.
This change uncovered a constellation that did not exist before.
A received packet is written into the page pool with multiple
fragments. On RTL93xx the head-of-line (HOL) feature limits
the number of receivable fragments perfectly. There will never
be a "buffer full" situation where the hardware only encounters
ring buffers that are held by the Linux kernel. On RTL83xx
this is slightly different:
- The driver programs free floating rings
- Only the ownership flag of the ring buffer decides if the
hardware can hand over a packet to the CPU.
- So the hardware can receive a packet even if it does not
completely fit into the available fragments.
With this there is a small chance that
- The buffer has less space than a just received packet
- The hardware generates an overflow (RUN OUT) interrupt
- With no completely received packet the hardware DOES NOT
generate a receive (DONE) interrupt.
So it is not sufficient to just look on the DONE interrupts.
The RUN OUT interrupts must be inspected as well. As the
current logic is quite cryptic enhance this as follows:
- Provide new RTL83xx/RTL93xx specific helpers
- Add new callbacks to the driver configuration structure
- Link the configuration with the new helpers
- Use the callbacks where needed.
While we are here:
- Enable only interrupts for active receive rings. Until
now the driver activated all receive interrupts (8/32)
although it supports only 2 rings.
- Use DIV_ROUND_UP instead of classic division for register
calculation.
Zoltan HERPAI [Mon, 15 Jun 2026 13:04:20 +0000 (13:04 +0000)]
kernel/zynq: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Jonas Jelonek [Sun, 2 Aug 2026 15:10:38 +0000 (15:10 +0000)]
realtek: pcs: rtl93xx: rename rxcal_ accessors to rxeq_
Split naming convention: rxeq_* accessors control equalizer state
(get/set a coefficient, toggle adapt); rxcal_* functions run an actual
calibration procedure (measure, decide, retry). 930x's accessor layer
predates this split and still used rxcal_ throughout; rename it to
match the convention already applied consistently on 931x.
dfe_taps_adapt/dfe_disable move too - despite looping over TAP1-4,
they just apply a fixed control action with no measurement or
decision-making, same as the single-coefficient accessors. init,
fgcal, leq_adapt_lock and vth_tap0_adapt_lock stay rxcal_ - they're
the calibration-flow entry points that call these accessors as
building blocks, and the *_adapt_lock ones specifically read back a
result to decide what to lock in.
Also rename 931x's dfe_disable_5g to rxeq_dfe_disable_5g for the same
reason - it's a fixed control action, not a calibration procedure.
Jonas Jelonek [Mon, 27 Jul 2026 20:29:37 +0000 (20:29 +0000)]
realtek: pcs: rtl931x: gate symErr success on actual link status
symErr reads 0 both when the link is clean and when there's no signal
at all to decode errors from - the counter only increments when the
PCS is actively decoding something and finds a mismatch, so a dead
link and a healthy one are indistinguishable from symErr alone.
Confirmed on hardware: symErr read 0x0 while the port had no link.
Add rtpcs_931x_sds_10gr_link_up(), reading the same status bit as the
vendor SDK's _phy_rtl9310_linkSts_get() default case, and require it
alongside a low symErr count before declaring a calibration check
successful. A link that isn't actually up yet now keeps the retry
loop going instead of being misread as a clean, working link.
Also observed on hardware: the retry budget sometimes runs out while
symErr is still nonzero, but the link comes up and works fine anyway -
the count just hasn't fully settled within the budget. Since that's
not an actual problem, keep the final message at dev_dbg when
link_up is true; only warn when the link genuinely never came up.
Jonas Jelonek [Wed, 29 Jul 2026 19:41:33 +0000 (19:41 +0000)]
realtek: pcs: rtl931x: average VTH samples instead of one point-sample
rxcal_fiber_adapt() locked in whatever a single rxeq_vth_get() call
returned after a fixed 200ms adapt window - no check that the reading
was representative rather than a transient/noisy excursion. Observed
on hardware: whenever the locked VTH wasn't 0xa (the reset baseline),
the link behaved worse; recalibrating a link that was already working
could leave it worse than before, which a single unlucky sample
locked in as final is a plausible cause of.
RTL930x's own analogous case (leq_adapt_lock) already avoids exactly
this by sampling 10 times over ~100ms and averaging rather than
trusting one read. Do the same here: settle for 100ms, then sample
VTH 10 times over ~100ms and lock in the rounded average, using
DIV_ROUND_CLOSEST() rather than an open-coded round-to-nearest.
Jonas Jelonek [Mon, 27 Jul 2026 18:46:36 +0000 (18:46 +0000)]
realtek: pcs: rtl931x: lock manual mode before reset values
reset_leq_dfe() wrote reset values for LEQ and VTH/TAP0-4 before setting
their manual-mode enable mask, matching the vendor SDK's own instruction
order. On a first-ever call this is harmless, but calibration may leave
those in continuous live auto-adapt when it returns, so on a second
calibration attempt those fields can still be adapt-driven at the moment
reset_leq_dfe() writes "0" into them - the adapt engine can overwrite
that write before the enable-mask lands a few instructions later, locking
in whatever it had drifted to instead of the intended baseline.
Set the manual-mode enable mask first instead, so the fields are
guaranteed passive before their reset values are written, regardless
of what state a previous calibration pass left them in.
Testing on hardware suggests that this matters at least for VTH/TAP0-4,
showing a drift of coefficients throughout multiple calibration runs
without this change. With this change, it remains stable across runs.
Jonas Jelonek [Mon, 27 Jul 2026 18:43:55 +0000 (18:43 +0000)]
realtek: pcs: rtl931x: add some debug prints to RX calibration
Add some debugging aid to the RX calibration, making it easier to spot
eventual issues caused by calibration. While the calibration has been
tested, this happened only on a small set of devices.
Adds rtpcs_931x_sds_rxeq_leq_get_coef() to read back where LEQ
auto-adapt actually settles in rxcal_leq_adapt(), mirroring what
rxcal_fiber_adapt() already does for VTH. Shares the existing
930x gray-to-binary helper since it's pure bit math, not
variant-specific. Promote it to a generic helper instead of
930x-specific.
Jonas Jelonek [Tue, 28 Jul 2026 22:21:01 +0000 (22:21 +0000)]
realtek: pcs: rtl931x: replace open-coded writes with named setters
Replace the plain field writes in rtpcs_931x_sds_reset_leq_dfe() with
the rxeq_* setters, now that both wire-up commits have given them real
calibration callers. Keeps the register-level detail out of the reset
sequence and gives it named accessors instead of raw write_bits() calls.
Some bits touched by the original reset writes fall outside any known
coefficient field (reg 0xd bits [1:0], reg 0x12 bits [15:12]/[3:0]).
These are kept as separate, explicitly commented raw writes rather than
folded into the setters, since the setters are scoped to match the
vendor SDK's real per-field accessors and narrowing them silently would
drop those undocumented-but-required bits.
Jonas Jelonek [Tue, 28 Jul 2026 22:19:49 +0000 (22:19 +0000)]
realtek: pcs: rtl931x: wire up RX calibration for 10G fiber
Port the vendor SDK's _phy_rtl9310_fiber_adapt() as
rtpcs_931x_sds_rxcal_fiber_adapt(), dispatched from post_config for
RTPCS_SDS_ATTACH_FIBER when hw_mode is 10GBase-R (1G/100M fiber isn't
calibrated by the vendor SDK either).
Add the rxeq_tap_*/rxeq_vth_* setters (set_value, set_adapt) needed to
drive it: fiber calibration runs VTH/TAP0 auto-adapt for 200ms, then
samples the auto-adapted VTH and locks it in, forces TAP0 to a fixed
value (31, per the vendor SDK), and re-locks manual mode, before letting
DFE TAP1-4 auto-adapt freely and verifying via a symbol-error recheck
loop.
Sampling VTH needs the SerDes' debug-readback routing. Add
rtpcs_931x_sds_set_debug() and rxeq_vth_get() for it, mirroring
_phy_rtl9310_dbg_set()/_phy_rtl9310_dfe_get().
The final symbol-error recheck deliberately deviates from the vendor
SDK's shape (adapt once, recheck 3x at 150ms, require exactly 0):
symErr's field is only 8 bits wide and reads as a saturated 0xff right
after rx_reset(), which looks like "link hasn't relocked yet" rather
than a genuine error count - 10G optical relock can plausibly take
longer than 150ms. Instead, recheck more times with more patience per
check and no reset in between (so a settling link isn't interrupted),
and tolerate a small nonzero symbol-error count rather than requiring
exactly 0.
rtpcs_931x_sds_fiber_get_symerr() already existed but was unused;
wire it up alongside the existing rtpcs_931x_sds_clear_symerr().
Jonas Jelonek [Tue, 28 Jul 2026 22:09:39 +0000 (22:09 +0000)]
realtek: pcs: rtl931x: wire up RX calibration for PHY-attached ports
Add post_config, run after activate() like on RTL930x, dispatching RX
calibration by attachment. Port the vendor SDK's _phy_rtl9310_leq_adapt()
as rtpcs_931x_sds_rxcal_leq_adapt() for the PHY-attached case, built on
new rxeq_leq_set_coef()/rxeq_leq_set_adapt() setters and the
existing but unused rx_reset().
Add rtpcs_931x_sds_dfe_disable_5g() for the one-shot operation the SDK
issues before calibrating PHY-attached and PCB-adapt ports. Presumably,
this quiesces DFE auto-adapt on the 5G companion analog block to prevent
it from interfering with DFE adaption during calibration.
Fiber and DAC attachments remain a TODO in post_config's dispatch.
kernel: drop redundant TCP fraglist GRO pull check
The patch adds a pre-check to tcp_gro_receive() so that an skb which
cannot be pulled up to the GRO offset is flushed instead of reaching the
BUG() in __skb_pull(). Upstream has since fixed the same bug inside the
callee, which leaves the pre-check with nothing to protect:
skb_gro_receive_list() now rejects the short skb itself and pulls with
skb_pull() rather than the __skb_pull() that carries the BUG(). It is
the only function the is_flist branch of tcp_gro_receive() calls, so no
path is left uncovered. The fix is present in both pinned kernels,
6.12.100 and 6.18.41.
Dropping the pre-check also restores upstream's intended handling: on
failure skb_gro_receive_list() sets NAPI_GRO_CB(skb)->flush, so the skb
is delivered through the normal receive path instead of being held as a
new GRO head. Short-circuiting on the local flush skipped that.
The patch keeps applying cleanly only because the fix landed in a
different function.
Assisted-by: Claude:claude-opus-5 Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de> Link: https://github.com/openwrt/openwrt/pull/24524 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The per-partition branch of w_init() tested econet,enable-remap on the parent
nand node (np) instead of the partition being iterated (part_np). That branch
only runs when np does not carry the property, so the test was always false and
the loop skipped every partition. As a result econet,enable-remap on a
partition node was a silent no-op: no partition ever registered a remap range,
and "enable-remap set for ..." was never printed.
Read the property from part_np so per-partition enable-remap works as
documented. Boards that place the property on a partition now register that
range; boards that place it on the nand node are unaffected.
Paweł Owoc [Sun, 2 Aug 2026 06:51:39 +0000 (08:51 +0200)]
tools: elfutils: fix uio header inclusion
Fixes arm64 build failures by replacing <linux/uio.h> with POSIX <sys/uio.h>
to avoid header redefinition conflicts.
gnulib's fcntl.h ends up including glibc's fcntl.h and fcntl-linux.h
which includes glibc's types/struct_iovec.h,
thats where the redefinition happens.
the lines that use <linux/uio.h> are antiquated and were never necessary.
it can be traced back to the original 2014 change that added the file with aarch64 support
in upstream commit 66637fa21044ac0058b25522f473669e73de328b
it was never necessary to use the linux header over the glibc headers,
as elfutils only needs the iovec struct and that struct was present since glibc 2.0 in the 1990s
Restore the original mac80211.sh behavior by setting noscan when
fixed_freq is enabled for sta, adhoc and mesh modes. This ensures
correct channel width operation for fixed-frequency links and
matches the legacy mac80211.sh behavior.
mediatek: filogic: add support for COMFAST CF-WA933
The Comfast CF-WA933[1] is an outdoor dual-band WiFi 6 access
point/router. They also OEM their routers for other providers. This PR
adds support based on, and substantially updates, the downstream device
definition[2] from Wayru, one such white label client.
It can be powered by a 12V DC barrel jack (standard 5.5x2.5mm, center
positive) or via 802.3af POE.
Hardware summary:
- SoC: MediaTek MT7981A
- RAM: 256 MiB
- Flash: SPI-NAND 128 MiB (Factory uses 64M; see details below to use
the full 128M!)
- WiFi (MT7976DA): dual-band 802.11ax
- Ethernet (MT7531AE): 3x gigabit: 1x WAN + 2x LAN (labeled lan1/lan2).
- Button: reset
- LEDs: Power (always on), WLAN, WAN, LAN1, LAN2
- Serial: Internal header (Four unpopulated headers, clearly labeled)
The serial number is stored as an ASCII string at Factory 0xe100.
Disassembly:
Unscrew the six 3mm hex bolts on the dome and the six 5mm bolts on the
side of the arm, then lift the dome. For reassembly, make sure the large
O ring is in the groove in the dome.
OpenWrt installation:
1. Connect to Ethernet on the WAN port. Manually set your IP address to
192.168.1.10 (important!)
2. Upload the OpenWrt sysupgrade image at http://192.168.1.1
The default U-Boot partition layout does not expose the full flash
capacity. Change the mtdparts U-Boot environment variable before
rebooting and then installing the image for the 128 MiB variant through
the same bootloader recovery/upgrade page.
Method 1: Using the serial console
1. Disassemble the unit and connect to the serial console (115200 8N1).
Leave 3.3V disconnected.
2. On the boot loader, go straight to "0. U-Boot console"
3. Then enter:
setenv mtdparts 'nmbm0:1024k(bl2),512k(u-boot-env),2048k(factory),2048k(fip),117248k(ubi)'
saveenv
reset
Return to vendor firmware:
1. If you have changed the mtdparts environment variable, undo the
change by setting:
mtdparts 'nmbm0:1024k(bl2),512k(u-boot-env),2048k(factory),2048k(fip),65536k(ubi)'
2. Re-enter the same bootloader recovery/upgrade page.
3. Upload a stock COMFAST firmware image, e.g. from
http://www.comfast.com.cn/index.php?m=content&c=index&a=show&catid=85&id=773
Robert Marko [Mon, 3 Aug 2026 09:44:15 +0000 (11:44 +0200)]
qualcommax: ipq50xx: build-in PTP support
When images are built with CONFIG_ALL_KMODS=y which are all buildbot built
images, then the STMMAC_ETH driver will get demoted to a module.
This is due to ALL_KMODS including kmod-ptp which selects the full PTP 1588
support instead of just the auto selected PTP_1588_CLOCK_OPTIONAL.
That causes PTP_1588_CLOCK_OPTIONAL to get deselected, STMMAC driver built
as a module instead of being built-in and then its not shipped in the device
images leading to no working wired networking.
So, lets simply enable full PTP 1588 support as built-in into the kernel so
that STMMAC does not get demoted to a module and restores wired networking.
For 40,000 ns at 100 MHz this is floor(0.061) == 0, so the driver
deterministically returns -ERANGE and pwm-fan fails to probe on every
boot:
pwm-fan pwm-fan: failed to enable PWM
pwm-fan pwm-fan: Failed to configure PWM: -34
pwm-fan pwm-fan: probe with driver pwm-fan failed with error -34
Probe returns before the tachometer IRQ is requested and before
fan-supply is claimed, so the board loses fan RPM reporting and the
vcc_fan 5V regulator stays disabled. The fan never spins and the DTS
cooling-maps (trips at 50/75/100 C) have no cooling device to bind to.
This is the same defect fixed for qualcommbe in commit 8db23dc91a01
("qualcommbe: fix pwm period calculation") by Kenneth Kasilag, whose
rationale explicitly calls out 25 kHz four-wire fan PWM. qualcommax
carries its own copy of the pwm-ipq driver and was not covered by that
fix. The patch added here is that work backported to qualcommax, with
authorship preserved; the base driver differs slightly between targets
so the hunks were rebased onto the qualcommax copy.
Confirmed on hardware. The board was tested on the 6.12 kernel, which
this target has since dropped; the pwm-ipq driver source is identical
under 6.12 and 6.18, so the patch and its effect are unchanged. Before,
driving the PWM directly from userspace on a GL-AXT1800 running
r35591-d0110a25ed:
Jonas Jelonek [Sun, 2 Aug 2026 20:02:10 +0000 (20:02 +0000)]
realtek: board: add patch to fix boot hang
Add a patch to fix boot hang on some devices after 7cc31af7bdd4
("realtek: convert to generic machine initialization"), reusing
upstream's implementation of Realtek board setup. The issue came up on a
Linksys LGS352C device, causing total silence and a hang after
rt-loader's last line "Booting kernel from 0x80100000 ...".
While the OpenWrt downstream version operated on the plain appended
device tree using a pointer, the upstream implementation copies the FDT
into a 16 KiB buffer. Given the following survey, this may be too small
for some devices:
The patch relaxes buf_verify()'s "Non-matching signing type" check so
that an rsa-sha2-256 signature is accepted against an ssh-rsa key.
Dropbear no longer needs the help: both sides of that comparison are now
taken from the wire's own algorithm names, so a compliant client
satisfies expect_sigtype == sigtype unaided.
Tracing the provenance in 2026.92, since it is what the removal rests
on. svr-authpubkey.c:113 reads the algorithm name out of the
SSH_MSG_USERAUTH_REQUEST and :126 turns it into sigtype with
signature_type_from_name(); that value is what :233 hands to buf_verify()
as expect_sigtype. signkey.c:655 parses the type name out of the
signature blob through the same signature_type_from_name(), and :659
compares the two. Neither is derived from the key format found in
authorized_keys: :132 maps the signature type back to the key algorithm
with signkey_type_from_signature() purely for the checkpubkey() lookup.
RFC 8332 section 3 has a client using rsa-sha2-256 send that name in the
userauth request and in the signature both, so the two agree and the
check passes - with an ssh-rsa key in authorized_keys, which is the case
the patch was written for.
Confirmed rather than reasoned: built pristine 2026.92 with this
package's defaults (DROPBEAR_RSA 1, DROPBEAR_RSA_SHA1 0) and logged in
over publickey with an OpenSSH client pinned to
PubkeyAcceptedAlgorithms=rsa-sha2-256. It succeeds, and the server
reports "Pubkey auth succeeded ... with ssh-rsa key" - an ssh-rsa entry
in authorized_keys, an rsa-sha2-256 signature, no patch.
Keeping the patch has an effect of its own. With DROPBEAR_RSA_SHA1 0,
signature_type_from_name("ssh-rsa") falls through to
signkey_type_from_name() and returns DROPBEAR_SIGNKEY_RSA, which is 0.
That is not DROPBEAR_SIGNATURE_NONE, so the patch's own "No signature
type" guard passes it, and expect_sigtype == DROPBEAR_SIGNATURE_RSA_SHA256
skips the type check. buf_rsa_verify() then calls rsa_pad_em(), whose
switch has no case for 0 and ends in default: assert(0), so the process
aborts. Upstream's unconditional check rejects the mismatch instead.
It is also narrower than upstream's in a second way: the replacement
sits inside #if DROPBEAR_RSA / #if DROPBEAR_RSA_SHA256, while the check
it displaces is unconditional. An ECDSA or Ed25519 only build therefore
has no expect_sigtype check at all today, only the "No signature type"
guard. Dropping the patch restores the check for every configuration,
not just this package's default one.
buf_verify() runs only after checkpubkey() has succeeded, so the abort
needs a key already listed in the target's authorized_keys - post-auth,
not an authentication bypass.
The patch's extra DROPBEAR_SIGNATURE_NONE guard is not lost with it:
svr-authpubkey.c rejects that case before buf_verify() is reached.
Murad Rabadanov [Wed, 29 Jul 2026 05:52:42 +0000 (08:52 +0300)]
mediatek: filogic: add support for netis N6 V2
netis N6 V2 is a MT7981B-based router, hardware-compatible with
netis NX32U (confirmed via bootloader cross-flash). GPIO mappings
not covered by the vendor DTS were verified against NX32U and via
live link/carrier testing on switch ports, plus direct LED-toggle
confirmation on the physical device.
Hardware:
SoC: MediaTek MT7981B (Filogic 820)
RAM: 256 MiB DDR3 (ESMT M15T2G16128A-AZR1-EFB, DDR3-1866)
Flash: 128 MiB SPI-NAND
Ethernet: 4x 1GbE (mt7531 switch: wan, lan1, lan2, lan3),
2.5GbE internal CPU-switch link (gmac0, 2500base-x)
WiFi: MT7981 integrated 2.4GHz + MT7976C 5GHz radio,
802.11ax, 2x2 MU-MIMO, HE160 supported (confirmed live;
vendor firmware ships with HE80 for the AX1800 rating)
USB: 1x USB 3.0 (vbus GPIO 23, active high)
Buttons: mesh/rfkill (GPIO 0), reset (GPIO 1)
LEDs: power (GPIO 4), status (GPIO 5), wan (GPIO 9),
wlan 2.4GHz (GPIO 34, phy0tpt trigger),
wlan 5GHz (GPIO 35, phy1tpt trigger),
usb (GPIO 13, usbport trigger)
all active low
UART: 115200n8, uart0
LAN address matches the label on the device enclosure. WAN uses
macaddr_factory_1fef26 on switch port@0, LAN/CPU uses
macaddr_factory_1fef20 on port@6 (mt7531 switch). WiFi MACs are not
set explicitly in DTS -- mt76 derives them from the radio's own
calibration data, confirmed live to match the stock firmware value.
The USB LED (GPIO 13) was missed in the initial GPIO mapping pass --
it isn't referenced anywhere in the vendor DTS or any other board
signal, so it went unnoticed until manual GPIO toggling (`gpio clear
13` at the U-Boot prompt) confirmed it live on the physical device.
The USB LED on GPIO 13 uses the usbport trigger with trigger-sources
on both xhci ports, hence kmod-usb-ledtrig-usbport in DEVICE_PACKAGES.
The included U-Boot defenv for this board also avoids a silent
failure in ubi_write_production/ubi_write_recovery: these call
`ubi remove <vol>` without first detaching/reattaching the UBI
device, which fails silently on a busy volume while the boot script
proceeds as if it succeeded. Worked around here by adding
`ubi detach ; ubi part ubi ;` before the remove, a pattern already
used in other boards' defenvs (see issue #18231). Only this board's
defenv is touched -- other boards' defenv files are unchanged.
Known upstream issue (not specific to this port): probing
u-boot-env-layout on the ubootenv/ubootenv2 UBI volumes logs
"Invalid calculated CRC32" on every boot, see mediatek/filogic
issues #21876 and #22383.
Installation:
Requires network access to stock firmware SSH (enabled by default)
and a TFTP server on the same subnet.
1. Set up a TFTP server on your PC at 192.168.1.254, serving the
files from this release.
2. SSH into stock firmware: ssh root@192.168.1.1
3. Copy bl31-uboot.fip to the router and write it to the FIP
partition: mtd write bl31-uboot.fip FIP
4. Erase the ubi partition: mtd erase ubi
5. Reboot. The new bootloader will detect the missing production
image and automatically fetch initramfs-recovery.itb via TFTP.
6. Once recovery has booted, SSH in again and sysupgrade to the
production image: sysupgrade squashfs-sysupgrade.itb
uboot-airoha: fix eMMC boot failure caused by redundant env
The an7581/an7583 configs enable redundant environment support,
but do not define CONFIG_ENV_OFFSET_REDUND.
When running `saveenv`, U-Boot tries to write the redundant environment
to MMC. Without a valid redundant environment offset, the data may be
written to an incorrect location and overwrite critical boot data such
as the GPT, BL2/preloader or BL31+U-Boot FIP.
This causes the board to fail booting after saving the environment.
Define CONFIG_ENV_OFFSET_REDUND so the redundant environment is stored
at a valid eMMC offset and no longer corrupts the bootchain.
generic: backport net-dsa-realtek use devm_mutex_init for locks
Backport four upstream commits that convert mutex_init() calls to
devm_mutex_init() in the Realtek DSA driver family. With
CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() must be called before a
mutex is discarded; using the devm variant handles this cleanup
automatically and avoids leaking a warning on driver removal/failure.
Added patches (applied to both backport-6.12 and backport-6.18):
- 944-01: net: dsa: realtek: rtl8365mb: use devm_mutex_init for mib_lock
- 944-02: net: dsa: realtek: use devm_mutex_init for regmap lock
- 944-03: net: dsa: realtek: use devm_mutex_init for vlan_lock
- 944-04: net: dsa: realtek: use devm_mutex_init for l2_lock
Ahmed Naseef [Fri, 24 Jul 2026 03:52:07 +0000 (07:52 +0400)]
econet: en7528: add UBI support to DASAN H660GM-A
Move the DASAN H660GM-A root filesystem from a raw squashfs in the tclinux
partition to UBI, following the layout already used by the en751221
ChinaMobile GS3101.
tclinux is split into an explicit 4MB tclinux_kernel partition holding the
raw LZMA kernel and a tclinux_rootfs partition covering the remainder. The
latter is concatenated with the unused "unknown" partition into a single UBI
volume, giving 153MB on the Airtel variant and 41MB on the Generic one. The
two regions are not adjacent, so this needs mtd virtual concat, which is
enabled for the subtarget.
The TRX plus UBI image recipe is identical to the one the GS3101 uses, so
factor it out into a Device/tclinux-ubi template instead of duplicating it.
The .trx is written linearly into tclinux by the vendor installer, so an
oversized image would run past its end into tclinux_slave and destroy the
vendor firmware in the alternate slot. FACTORY_SIZE guards against this and
is set to the size of the partition the .trx is written into.
Existing installations have to be reflashed with the .trx rather than
sysupgraded, since the ubi MTD only appears once the new device tree is
running.
There are 2 ways to install OpenWrt:
- via an intermediate RSA-signed vendor's image or
- via UART && TFTPd
Migration to OpenWrt via OEM firmware:
- Download the migration image from
https://drive.google.com/drive/folders/1BKVarlwlNxf7uJUtRhuMGUqeCa5KpMnj
(The folder is Cudy's official "Cudy Intermediary OpenWrt Firmware" resource)
- Upload the migration image via OEM web interface
- After flashing, OpenWrt is accessible via http://192.168.1.1
- Flash the official OpenWrt image
Install using UART & TFTP:
- Connect to UART.
- Connect to LAN and set your IP to 192.168.1.88/24.
- Configure a TFTP server to serve
openwrt-mediatek-filogic-cudy_wr3000u-v1-initramfs-kernel.bin file
and run the TFTP server.
- Press reset and power-on the router. Hold the reset button for 5 seconds
- TFTP error: 'File not found' appears and MTK console becomes available
- Enter the following commands in the console:
setenv bootfile openwrt-mediatek-filogic-cudy_wr3000u-v1-initramfs-kernel.bin
tftpboot
bootm
- After booting to initramfs, via http://192.168.1.1 flash
openwrt-mediatek-filogic-cudy_wr3000u-v1-squashfs-sysupgrade.bin
- After flashing, OpenWrt is accessible via http://192.168.1.1
If you fail to flash the device,
you can use TFTP to flash back to the original firmware:
- Download the original firmware from
https://www.cudy.com/pages/download-center/wr3000u-256mb-1-0
- Connect to LAN and set your IP to 192.168.1.88/24.
Configure a TFTP server and an recovery.bin firmware file
- With the router off, press the RESET button.
While the router is turning on,
the button should continue to be pressed for at least 5 seconds
- After 1-2 minutes the original firmware is available on http://192.168.10.1
Jonas Jelonek [Fri, 31 Jul 2026 13:39:38 +0000 (13:39 +0000)]
realtek: dsa: rtl931x: downgrade print_matrix to debug
Downgrade rtldsa_931x_print_matrix from pr_info to pr_debug to reduce
the massive amount printed during boot (64 lines). There doesn't seem
any benefit right now for keeping this at info level. And RTL931X is
the only variant that uses info-level print right now, all others
already use pr_debug.
Debug output can be activated individually for people who need this for
testing/debugging.
qualcommax: qca_edma: give the DSA conduit a stable MAC address
edma_probe() assigns a random address unconditionally, so the conduit
changes its MAC on every boot, and with it every DSA user port that has
no address of its own and therefore inherits the conduit's.
The conduit is a DMA engine behind the switch and has no address of its
own, which is why no board describes one for it. Take the address from
the switch this conduit serves instead: its ports carry the board's
addresses, either from DT or patched in by the bootloader, so this needs
nothing added per board. Keep the random address for the case where the
switch describes no address either.
Assisted-by: Claude:claude-opus-5 Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de> Link: https://github.com/openwrt/openwrt/pull/24512 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
John Audia [Sat, 25 Jul 2026 16:29:55 +0000 (12:29 -0400)]
kernel: netfilter: add kmod-nft-core dep to kmod-nf-flow
nf_flow_table.ko now links in the flowtable path discovery code
(nft_flow_route() and friends), which was moved out of
nft_flow_offload.c and references nf_tables symbols directly. This
makes nf_flow_table.ko depend on nf_tables.ko at load time, so
kmod-nf-flow needs kmod-nft-core.
Upstream: 93d7a7ed0734 ("netfilter: flowtable: move path discovery infrastructure to its own file")
kernel/modules: set CONFIG_UML_SOUND for UML if kmod-sound-core is selected
This was changed in upstream linux kernel with:
|commit db4bfcba7bb8 um: Fix hostaudio build errors
|Author: Randy Dunlap <rdunlap@infradead.org>
|Date: Tue Aug 1 22:15:00 2023 -0700
|
| um: Fix hostaudio build errors
|
| Use "select" to ensure that the required kconfig symbols are set
| as expected.
| Drop HOSTAUDIO since it is now equivalent to UML_SOUND.
|
| Set CONFIG_SOUND=m in ARCH=um defconfig files to maintain the
| status quo of the default configs.
|
| Allow SOUND with UML regardless of HAS_IOMEM. Otherwise there is a
| kconfig warning for unmet dependencies. (This was not an issue when
| SOUND was defined in arch/um/drivers/Kconfig. I have done 50 randconfig
| builds and didn't find any issues.)
| [...]
The reason why this was not spotted is because of IOMEM. We would need
to have a device that requires IOMEM first and the obvious choice would
be VFIO_PCI. But none of the pci features are set for the UML target.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Qingfang Deng [Thu, 30 Jul 2026 01:20:05 +0000 (09:20 +0800)]
ppp: fix precompiled filter option
The upgrade to 2.5.0 accidentally dropped the CPP defines, so the
precompiled-active-filter option has been missing and the demand dialing
option in uci has been broken since then. Add the missing defines.
Fixes: 9cecf2b16e0e ("ppp: update to 2.5.0") Closes: https://github.com/openwrt/openwrt/issues/24454 Signed-off-by: Qingfang Deng <dqfext@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24467 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Felix Fietkau [Fri, 31 Jul 2026 01:19:42 +0000 (03:19 +0200)]
hostapd: only follow a station channel on radios that hold a link
A station MLD is configured across every radio it may use, which marks all
of those radios as channel following. Only the radios the station actually
holds a link on have a channel to follow; the rest waited for one that never
arrived, so they ignored their configured channel and kept whatever ACS had
picked at start up. Later channel changes were dropped as well, because the
pending follow was treated as authoritative.
Track the frequency reported through apsta_state per radio and let a radio
without one apply its own configuration. The supplicant marks the radios
holding no link when the station completes an association, and repeats the
notification on link reconfiguration, so radios are handed back and forth as
the station adds or drops links rather than staying stuck on the first
association.
Felix Fietkau [Thu, 30 Jul 2026 08:12:06 +0000 (10:12 +0200)]
wifi-scripts: keep radio config out of the MLD configuration
wpad decides whether to keep or tear down an MLD interface by comparing the
whole configuration object, which embedded the full device configuration of
every participating radio. Any radio level change, such as a channel or
txpower update, therefore destroyed and recreated the station MLD and
dropped the backhaul link. Neither hostapd nor wpa_supplicant reads
radio_config; it is only used locally to resolve the phy.
Jonas Jelonek [Wed, 22 Jul 2026 21:31:14 +0000 (21:31 +0000)]
realtek: pcs: move USXGMII submodes out of sds_mode enum
Carrying all six USXGMII submodes as distinct rtpcs_sds_mode values
forced every switch/case over hw_mode to enumerate them individually,
even though almost none of that code actually cares which submode is
active; a couple of places on 930X do, but only to tell SXGMII/QXGMII
apart from the rest.
Collapse them into a single RTPCS_SDS_MODE_USXGMII and introduce
rtpcs_sds_usxgmii_submode for the cases that still need the
distinction, threading it explicitly through hw-mode selection and
set_hw_mode instead of overloading the mode enum for it.
Jonas Jelonek [Thu, 30 Jul 2026 15:52:08 +0000 (15:52 +0000)]
realtek: pcs: fold usxgmii_config parameters into the function
Both call sites always pass the same constants; there's no actual
variation to justify exposing opcode/am_period/an_table/sync_bit as
parameters. Inline them and keep their names as comments so the
meaning of each write isn't lost. Also clarify the QHSG naming in the
function's leading comment.
The USXGMII config took a parameter to set for all USXGMII alignment
markers. However, we and the SDK always set all markers to zero except
for some special cases. Since this doesn't require a parameter, just
break it down to clearing the alignment markers.
To reduce the number of calls and writes, the pattern writing the two
halves of a register separately is reduced to a write of the full
register.
Jonas Jelonek [Wed, 29 Jul 2026 23:31:21 +0000 (23:31 +0000)]
realtek: pcs: drop rtpcs_sds_reg_field abstraction
reg and bit position for the autoneg control fields are identical
across all variants; only the page differs, and only for 931x. Since
that's the only axis that actually varies, replace the per-field
struct-of-structs with a single phy_page in rtpcs_config denoting the
page mirroring standard PHY registers for that variant.
Given that, there is now justification left to keep this abstraction.
Drop it for now. If needed in the future, it can be added back with a
proper user then.
Jonas Jelonek [Wed, 29 Jul 2026 23:12:07 +0000 (23:12 +0000)]
realtek: pcs: adjust init/probe prints
Drop a useless debug print that 838x_probe still has.
Also move the pcs_config print informing about the configuration to the
end of the configuration, now just showing up after the SerDes has been
configured successfully, not upfront.
Jonas Jelonek [Wed, 29 Jul 2026 22:52:53 +0000 (22:52 +0000)]
realtek: pcs: replace pr_ prints with dev_
There are still several pr_* prints in the driver, however using dev_*
equivalents are preferred. They add information about the attached
device. Switch all remaining pr_* calls to dev_*, adjusting the log
level of some of them to something more accurate (e.g. info -> debug,
info -> error).
Jonas Jelonek [Mon, 20 Jul 2026 21:35:53 +0000 (21:35 +0000)]
realtek: pcs: shorten some comments
Some comments have some unneeded information included, especially those
naming register fields often carrying CFG_ or REGX_ prefixes. They add
nothing useful to the purpose of a field. Drop them to slim down those
comments a bit.
Also adjust and drop some comments not needed anymore, mostly since the
information is already preserved elsewhere.
bcm27xx: move USB HID/sound to opt-in meta-packages
kmod-usb-hid, kmod-sound-core, and kmod-sound-arm-bcm2835 are
currently forced onto every bcm27xx image regardless of use case.
Move them into two new opt-in meta-packages, kmod-bcm27xx-hid and
kmod-bcm27xx-sound, filed under the input and sound submenus
respectively, following the same pattern as kmod-bcm27xx-i2c/-spi.
Still available via apk or menuconfig, just no longer default.
bcm27xx: dedupe shared device packages in image/Makefile
Several Device/* stanzas in image/Makefile repeat the same WiFi
firmware, WiFi driver, and LAN package lists verbatim --
Device/rpi-2 and Device/rpi-3 have byte-for-byte identical
DEVICE_PACKAGES blocks, and Device/rpi-4/Device/rpi-5 share the
same additional Ethernet trio.
Factor these into shared variables (WIFI_43430_FW, WIFI_43455_FW,
BRCM_WIFI_DRIVER, LAN_DRIVERS) so each device's actual package
list is defined once and reused, rather than copy-pasted across
five stanzas. No functional change: every device's final resolved
DEVICE_PACKAGES list is identical to before this patch.
bcm27xx: add bcm27xx-i2c/spi meta-packages, drop hardcoded kmods
Each bcm27xx generation needs a different combination of I2C/SPI
kernel modules -- bcm2708/2709/2710 use only the classic BCM2835
controllers, bcm2711 adds i2c-brcmstb, and bcm2712 additionally
needs the RP1-attached DesignWare controllers (i2c-designware-platform,
spi-dw-mmio) while lacking the classic Aux SPI block entirely.
Rather than requiring users to know which specific driver
combination their board needs, or baking that combination into
every device's default image regardless of whether I2C/SPI is
actually used, add two small meta-packages that resolve the
correct set automatically based on the selected subtarget:
- kmod-bcm27xx-i2c, added to target/linux/bcm27xx/modules/i2c.mk
- kmod-bcm27xx-spi, added to target/linux/bcm27xx/modules/spi.mk
Installing either pulls in exactly the right underlying kmods for
whichever bcm27xx board is being built.
Remove the now-redundant hardcoded i2c/spi kmod-* entries from
Device/rpi, Device/rpi-2, Device/rpi-3, Device/rpi-4 and Device/rpi-5
in image/Makefile.
bcm27xx: additional kernel optimizations on bcm2712
Further trim leftover hardware support inherited from other SoCs
and reference designs that don't apply to bcm2712: Broadcom
set-top-box (BRCMSTB/BCMA) support, and unrelated third-party
silicon (Microchip PHY/PCIe host, SMSC PHY, PLDA PCIe host,
Cadence MACB's PCI wrapper).
Keep CONFIG_ARCH_BRCMSTB and CONFIG_RTC_DRV_RPI enabled: the CM5's
firmware-backed RTC depends on this switch despite being unrelated
to actual set-top-box hardware. CONFIG_SOC_BRCMSTB/SOC_BUS/GLOB
also remain, pulled in via PHY_BRCM_USB's dependency chain.
bcm27xx: drop unused clocks/DMA, enable RP1 overlay on bcm2712
Follow-up changes to the bcm2712 kernel config:
- Drop CONFIG_COMMON_CLK_XGENE and CONFIG_DMA_BCM2708, not
applicable to this SoC
- Enable CONFIG_MISC_RP1, which loads RP1's device-tree overlay.
Also enable CONFIG_PCI_DYNAMIC_OF_NODES (listed for clarity).
bcm27xx: enable kernel hardening on bcm2711/bcm2712
Enable a set of standard kernel hardening options on both the
bcm2711 and bcm2712 targets to reduce attack surface:
- Enable KASLR (CONFIG_RANDOMIZE_BASE) and module ASLR
(CONFIG_RANDOMIZE_MODULE_REGION_FULL)
- Enable Seccomp sandboxing support
- Disable Magic SysRq (CONFIG_MAGIC_SYSRQ /
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE)
- Enable ARM64 Branch Target Identification (CONFIG_ARM64_BTI) on
bcm2712, restricting indirect branches to valid function-entry
landing pads to harden against ROP/JOP-style control-flow attacks
- Clean up related fault-injection config leftovers
- Drop CONFIG_PADATA, orphaned once its only selector
(CONFIG_DEFERRED_STRUCT_PAGE_INIT) was found unset in this config
Ahmed Naseef [Sun, 12 Jul 2026 14:50:05 +0000 (18:50 +0400)]
econet: en7528: manage the on-die MT7530 switch with DSA
The EN7528 integrates an MT7530 Gigabit switch, memory-mapped in the SoC
register space like the built-in switches of the MediaTek MT7988 and
Airoha EN7581/AN7583 SoCs. Its chip revision register reads 0x7530, so
unlike those three it is a genuine MT7530 core rather than an MT7531
derivative.
Until now the out-of-tree econet-eth driver programmed it as a flat
"dumb switch" that simply bridged the four LAN ports together and
exposed them as a single eth0. Hand it to the upstream mt7530 DSA
driver instead, so the ports come up as managed user ports lan1-lan4.
- Add an ID_EN7528 variant to the mt7530 driver, bound through the MMIO
glue with the "econet,en7528-switch" compatible. It reuses
mt7988_setup() and the indirect PHY accessors, but selects the CPU
port through the MT7530-style MFC register rather than the MT7531 CFC
one, and describes the CPU port as a fixed 1000FDX link to the SoC
MAC. The LAN GPHYs advertise EEE, but negotiating it drops frames
with some link partners, so the LPI capabilities are left empty and
phylink keeps EEE off.
- The frame engine and the switch are adjacent but separate blocks. The
ethernet node used to describe a single 64K window covering both,
which overlaps the switch node and makes the two drivers fight over
the region. Size it to the frame engine alone (0x8000) and give the
switch its own node, so both keep an exclusive claim:
- econet-eth acts as the DSA conduit. It derives from the size of its
own register resource whether the window still covers the switch, and
when it does not, skips the dumb-switch setup and the switch
source-MAC write. The econet-eth driver now carries this support, so
bump PKG_SOURCE_VERSION to pull it in. EN751221 and EN751627 keep
the full window and are unaffected.
- Enable the switch on the DASAN H660GM-A. The two variants share a
board, but their sockets are not numbered the same way: LAN1 is
switch port 1 on the Airtel unit and port 4 on the generic one, so
the port labels are assigned per board .dts.
This commit introduces OpenWrt U-Boot UBI layout support
for the COMFAST CF-WR632AX, enabling:
- Prolonged device lifetime by allocating most of the flash
to UBI (which takes care of wear-leveling)
- Maximum available storage space for OpenWrt
- Fully-featured U-Boot
- Effective recovery mechanisms
OpenWrt U-Boot UBI flash instructions
-------------------------------------
A device running stock firmware should be upgraded to the
latest standard OpenWrt firmware
(https://firmware-selector.openwrt.org/?target=mediatek%2Ffilogic&id=comfast_cf-wr632ax).
Back up critical data
---------------------
Console:
1. While the device is running OpenWrt with stock MTD partitions:
mtd dump BL2 > /tmp/BL2.bin
mtd dump u-boot-env > /tmp/u-boot-env.bin
mtd dump Factory > /tmp/Factory.bin
mtd dump FIP > /tmp/FIP.bin
2. Copy the backup files to your PC via SCP.
LuCI Web-UI:
"System" -> "Backup / Flash Firmware" -> "Save mtdblock contents"
Save mtdblock:
BL2
u-boot-env
Factory
FIP
Make sure the files were successfully downloaded to your downloads directory,
especially the Factory file.
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 generic OpenWrt firmware.
Upgrade it if necessary.
2. Obtain the installer image:
Build the installer from source
https://github.com/andros-ua/owrt-ubi-installer/tree/cf-wr632ax
or download a prebuilt image from the
https://github.com/andros-ua/owrt-ubi-installer/releases
3. Flash the openwrt*-ubi-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.
5. Once the installation finishes,
the status LED will turn solid amber for 5 seconds.
6. After the device reboots, perform a final sysupgrade using the
openwrt*-ubi-squashfs-sysupgrade.itb image.
Return to stock MTD
-------------------
1. Flash openwrt*comfast_cf-wr632ax-initramfs-kernel.bin
via sysupgrade
2. Copy files to /tmp on the device via SCP:
BL2.bin
u-boot-env.bin
Factory.bin
FIP.bin
openwrt*-squashfs-sysupgrade.bin
3. Restore stock MTD partitions:
apk add kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
mtd write /tmp/BL2.bin BL2
mtd write /tmp/u-boot-env.bin u-boot-env
mtd write /tmp/Factory.bin Factory
mtd write /tmp/FIP.bin FIP
4. Install the system:
sysupgrade /tmp/*sysupgrade.bin
BL2 and FIP Recovery
--------------------
Use mtk_uartboot to recover corrupted BL2 or FIP via UART:
https://github.com/981213/mtk_uartboot
Add an OpenWrt U-Boot ("UBI") layout variant for the TP-Link Archer
BE450. It replaces the vendor bootloader and the stock dual-image
layout with a single large UBI partition, extending the usable flash
to around 95 MiB, and ships a current U-Boot with TFTP recovery.
Hardware
--------
SoC: MediaTek MT7988D (Filogic 880)
Wi-Fi: MediaTek MT7992AV (BE7200, 2.4/5 GHz)
Flash: 128 MiB SPI-NAND
RAM: 512 MiB DDR4
Serial: 115200 8N1, header located next to the heatsink:
MAC addresses
-------------
The label MAC (base) is stored in tp_data/default-mac and is written
into the factory partition at offset 0x4 during installation:
eth0 (LAN): base (factory 0x4)
eth1 (WAN): base + 1
eth2 (LAN): base + 2
Wi-Fi: derived by mt76 from the factory EEPROM (2.4 GHz = base,
5 GHz = base with bit 0x10 set), matching the stock
layout behaviour.
Installation
------------
Requires a serial connection and a TFTP server. The device must be
running the stock-layout OpenWrt (tplink_be450) build.
1. From the running stock-layout OpenWrt, back up the vendor
bootloader and the calibration/MAC data. These cannot be
recovered otherwise:
Store boot.bin, tp_data.bin and the tp_data file contents
(MT7992_EEPROM.bin, default-mac) somewhere safe.
2. Boot the UBI-layout initramfs. Connect the PC to one of the LAN ports
(LAN1-3) and serve the recovery image from a TFTP server on the PC at
192.168.1.2. Interrupt the vendor U-Boot on the serial console
(Ctrl+C), then:
5. Create the UBI volumes. Warning: this permanently erases the
remaining vendor data, including tp_data - only proceed with the
backups from step 1 stored safely:
6. Write the factory data and the BL2 preloader. kmod-mtd-rw is
required to lift the read-only protection of the bl2 partition;
set up internet access first or upload the package manually:
Revert to stock firmware
------------------------
1. From the UBI-layout OpenWrt, force-flash the stock-layout OpenWrt
(tplink_be450) initramfs image; the board name differs, so
sysupgrade must be forced:
2. After booting into that initramfs, set up network access, copy
boot.bin and tp_data.bin from the backup to /tmp and restore the
vendor bootloader and data:
Add a U-Boot replacement loader for the TP-Link Archer BE450
(MT7988D, 128 MiB SPI-NAND). BL2 boots from spim-nand-ubi with DDR4;
the FIP and the redundant environment are stored in UBI volumes.
This replaces the vendor bootloader and the stock dual-image layout
with a single large UBI partition, freeing around 95 MiB of flash for
OpenWrt. The vendor layout keeps BL2 at flash offset 0x0, which is
where snand_write_bl2 places the first of its four redundant copies.
The W25M02GV SPI-NAND is split at the die boundary
(die 0 = rootfs, die 1 = data) to work around a stock U-Boot bug:
the die-select is broken, causing reads from die 1 to return
0xFF. If UBI wear-leveling relocated the layout volume to
die 1, U-Boot would fail to attach UBI, bricking boot.
Splitting the chip keeps all UBI metadata U-Boot reads from
die 0.
Stock U-Boot hardcodes the UBI attach window to 64 MiB;
the bootcmd replacement expands it to 128 MiB to use the
full die 0.
rootfs 0x00000000 128 MiB
data 0x08000000 128 MiB
Installation
------------
1. Build image for sophos_apx120 target
2. Start TFTP server in folder with
openwrt-ipq40xx-generic-sophos_apx120-initramfs-
uImage.itb
3. Plug in Serial TTL Adapter (115200 baud):
3. Short U26 pin 8 (first pin on left, top row on NAND
Chip, with ethernet port facing you) to ground for a
fraction of a second during power-on. Expected output shows
NAND detection and CRC warning, then U-Boot prompt.
4. In U-Boot run:
$ setenv bootdelay 5
$ setenv verify no
$ saveenv
$ tftpboot 0x84000000
openwrt-ipq40xx-generic-sophos_apx120-initramfs-uImage.itb
$ bootm 0x84000000
5. Setup Networking Transfer the sysupgrade image using a
HTTP server or scp
6. In OpenWrt run:
$ fw_setenv bootcmd 'set fdt_high 0x87000000 && \
set bootargs ubi.mtd=rootfs root=mtd:ubi_rootfs \
rootfstype=squashfs rootwait && nand device 1 && \
set mtdids nand1=nand1 && set mtdparts \
mtdparts=nand1:0x8000000@0x0(fs) && \
ubi part fs && ubi read 0x84000000 kernel && \
bootm 0x84000000#config@ap.dk01.1-c2'
$ ubiformat /dev/mtd9 -y
$ sysupgrade -n
openwrt-ipq40xx-generic-sophos_apx120-squashfs-sysupgrade.bin
7. Device should reboot into OpenWrt
Notes
-----
- With firmware version 1.0.019, the image drops directly
into a shell, so NAND glitching may be skipped.
- The platform sysupgrade script reflashes the entire
die-0 UBI partition via `ubiformat` — live volume
manipulation would leave the UBI layout in a state the
stock U-Boot rejects, which bricks the device.
Known Issues
------------
- Some device revisions have an TPM chip that
is not detected/supported or is broken
generic: backport-6.18: fix naming of rtl8365mb patches
Rename all 942-* backport patches for the Realtek rtl8365mb DSA driver
to prefix the kernel version with "v" (e.g. v7.2 instead of 7.2),
matching the naming convention used elsewhere for backport patches.
Affected patches:
- 942-01: use ERR_PTR
- 942-02: reject unsupported topology
- 942-03: use dsa helpers for port isolation
- 942-04: prepare for multiple sources
- 942-05: add table lookup interface
- 942-06: add VLAN support
- 942-07: add FDB support
- 942-08: add port_bridge_join/leave
- 942-09: add bridge port flags
Michael Pratt [Sun, 19 Jul 2026 21:13:30 +0000 (17:13 -0400)]
gettext-full: update to 0.24.2
Update to a newer bugfix release of gettext.
This version includes a commit to make adjustments
according to changes in gnulib in early 2025.
Add DEPENDS variable to package definition
in order to enforce the correct build order,
which should have been done when libunistring
and libxml2 packages were moved to openwrt core.
Michael Pratt [Sat, 18 Jul 2026 12:14:19 +0000 (08:14 -0400)]
tools: gnulib: fix build with latest glibc C23 changes
Backport a patch that covers a build problem with latest glibc
being used as the host standard C library during tools build.
The C23 standard changes some functions that used to drop qualifiers
like "const" or "volatile" and are now forced to preserve them
in the return type based on the input type at all times.
Developers of glibc have responded by making these functions
into macros after they are declared with prototypes.
This is not compatible with the way gnulib is written,
so when the functions are redeclared in gnulib,
the preprocessor expands the _function name_ itself
as if it is a macro name, but not fully,
which results in unusual looking build errors,
e.g. the failed processing of keywords that were never written
and have no business being in a prototype, or,
as a keyword that is expected to be there and nearly guarenteed
to work but mysteriously is not working, displayed as:
"error: expected identifier or '(' before _____".
The backport patch introduces and implements a new macro
in order to prevent function names from being interpreted as macros,
by wrapping it in parentheses for C, or simply placing it back for C++
in the first stage of macro expansion which satisfies the goal
of no further expansion taking place during preprocessing.
Add an additional patch for the functions declared
in the fts header, as this bug also applies to them,
however, this was overlooked by upstream gnulib,
likely because the bug is not presenting as an error.
Yet another patch corrects the order between
specifiers and attributes in GCC syntax for header
lib/fts.in.h which can be blamed on an upstream commit.
Specifically, the throw() or noexcept() keywords
must be before attributes at the end of a declaration.
There are two headers, lib/cdefs.h and lib/getopt-ext.h
that already demonstrate the correct order which is very
strictly necessary in the latest version of GCC
when compiling C++ code, and acceptable for C code,
as the "__THROW" macro is simply another attribute in that case.
Michael Pratt [Wed, 15 Jul 2026 18:06:05 +0000 (14:06 -0400)]
tools: gnulib: update to branch stable-202507
Move to the July 2026 update of the last 2025 stable branch.
This branch includes many new modules and changes to modules
that were previously patched, so many patches are dropped.
Newer gnulib now also has a proper fts header
in the form of a template file for variable definitions
that are set during configuration,
however, it still ends up named with an underscore,
so the patch 120-unmangle-darwin-fts-h.patch
in order to resolve differences between macOS and standard
fts headers is rewritten to patch the new header include guard
and the fts module file in order to name it without an underscore.
Michael Pratt [Wed, 22 Jul 2026 10:23:58 +0000 (06:23 -0400)]
tools: automake: do not error on missing conditional
Now that cond.m4 is not being overwritten and is actively used,
make it less aggressive on encountering an undefined conditional
not set by a macro which is itself conditionally called,
where the condition is set to intentionally not trigger the macro.
This prevents the need to further patch a configure.ac file
to edit the improper usage of or remove a disabled macro
which triggers the error "conditional ___ is not defined..."
in the cases where autoreconf is still necessary for another reason,
or, if this is the only build issue,
autoreconf can now be used to avoid this.
Instead of erroring, align the behavior of AM_CONDITIONAL
closer to the gnulib variant gl_CONDITIONAL
which ignores and disables the conditional in this case.
ndo_open() runs under rtnl_lock() nevertheless the driver adds
its own locking and disables interrupts. Additionally it sleeps
inside some of the sub functions. This leads to spurious errors:
[ 11.233001] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:271
[ 11.233029] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 710, name: ip
[ 11.233040] preempt_count: ffffffff, expected: 0
[ 11.233055] CPU: 0 UID: 0 PID: 710 Comm: ip Tainted: G W O 6.18.39 #0 NONE
[ 11.233082] Hardware name: Hasivo S1100W-8XGT-SE
[ 11.233290] Call Trace:
[ 11.233294] [<80112108>] show_stack+0x28/0xf0
[ 11.233337] [<8010bb78>] dump_stack_lvl+0x70/0xb0
[ 11.233378] [<80168b80>] __might_resched+0x144/0x15c
[ 11.233417] [<808f2b6c>] mutex_lock+0x20/0x6c
[ 11.233451] [<80669ad8>] __dev_open+0x14c/0x230
[ 11.233493] [<80669c00>] netif_open+0x44/0x94
[ 11.233512] [<8066e51c>] dev_open+0x40/0x78
Linus Torvalds released the next kernel after 6.19 as version 7.0
instead of 6.20. Rename the backported patch files accordingly so
their names correctly reflect the upstream release they originate
from. This is a pure rename (100% similarity), no functional changes.
Fix and improve support for AN7583. Muxing of SPI, MDIO and I2C is
now fully supported and working.
Fix I2C1 in master mode on AN7581. (this allows to replace the i2c-gpio
driver on Nokia Valyrian with the proper i2c-mt7621 driver).
Fix non-working switching of GPIO direction if GPIO control register were
already modified by bootloader and pinctrl would create a reserved
state. All GPIO control registers have two bits per GPIO but the driver
only set one which is now fixed.
Fix problem were a pinmux config or GPIO mode cannot be applied if pin
control register were already modified by bootloader. The driver expects
all pin control registers to have their reset default value. Now the
driver forces that reset default value during probe.
Worth to mention that on AN7583 the GPIO mode and alternate pin modes
are reversed in the reset default value. To achieve same behaviour as on
AN7581 (GPIO mode by default, board DTS applies pinmux), the default
value enforced during probe enables all GPIO mode bits. As consequence
all AN7583 board DTS need to explicitely activate mdio0 or spi pin
groups.
airoha: backport pinctrl patches from Linux mainline
Backport missing pinctrl patches that has been accepted in Linux
v6.19 and v7.2.
This includes moving the Airoha pinctrl driver from
drivers/pinctrl/mediatek to drivers/pinctrl/airoha. Due to this,
all existing pinctrl patches needed a refresh.
Downstream patches may change the output. If the GCC version doesn't
incooperate the patches somehow (hash, git commit, ...), ccache may not
invalidate existing cache.
Document the existing properties supported by the legacy RTL8367B
switch driver, including MDIO and GPIO SMI access, optional reset and
internal MDIO bus descriptions, external interface configuration, and
board-specific post-initialization register/value pairs.
kernel: rtl8367b: support post-init register writes
Allow boards to provide optional register/value pairs through the
realtek,init-regs property. Apply them after the chip-specific
initialization table and before configuring the external interface.
Keep the property a no-op when absent. Reject malformed, oversized or
non-16-bit entries, and propagate register write failures. While at it,
remove a redundant trailing blank line at the end of the file.
Georgi Valkov [Thu, 16 Jul 2026 09:28:00 +0000 (12:28 +0300)]
mac80211: mwifiex: replace one-element arrays with flexible array members
Replace deprecated one-element arrays with flexible array members.
CONFIG_FORTIFY_SOURCE reports the following warning when
one-element arrays are used as variable-length buffers:
sta_cmd.c:1033 mwifiex_sta_prepare_cmd
memcpy: detected field-spanning write (size 84) of single field
"domain->triplet" at .../marvell/mwifiex/sta_cmd.c:1033 (size 3)
Convert affected structs to use flexible array members.
- Preserve existing wire layouts.
- Use DECLARE_FLEX_ARRAY() for structs inside affected unions.
Add a change_mtu operation, so the length the switch may deliver to the
CPU follows the conduit MTU instead of keeping the value programmed when
the interface came up.
To avoid trouble with the receive buffer, adapt the head of line budget
along with it. Those registers limit how many packets the hardware may
append to a receive ring, and deriving that limit from a frame of
maximum length makes the smallest MTU pay the price of the largest. With
400 byte fragments a 1626 byte frame occupies five of them, which leaves
128 / 5 = 25 packets per ring, while the 1530 byte frame of a tagged
conduit at its idle MTU needs four and fits 32.
The two limits move in opposite directions, so the order matters: on the
way up the budget shrinks before the switch is allowed to hand over
larger frames, which keeps the ring from ever running a budget meant for
smaller ones. On the way down it grows only after the switch has stopped
handing over the larger frames, which narrows that window rather than
closing it, as the ring may still hold frames of the previous size. The
pair runs under the lock the rest of the driver programs those registers
with, as the transmit watchdog is not serialised against an MTU change.
The budget comes from the config, one function per family, and opening
the interface calls it too: RTL83xx has none to resize, as its rings are
free floating, so it writes the ring size of zero that its reset paths
used to write themselves.
Nothing else has to follow, as the receive buffers are of a fixed size.
The largest MTU comes from the config too, one value per family: 10000
bytes on RTL838x and 12288 on the others, less the frame overhead. Those
are the limits the DSA driver already declares in its rmon ranges. A
frame must also fit into a single skb, whose linear part and fragments
hold 400 bytes each, so the operation refuses above an MTU of 7174 on
every family, well below what the switches would take. The fragment
size carries a TODO of its own, and raising it lifts that bound towards
the hardware one.
That remaining window is why every accepted change carries a warning. A
closed interface has neither a ring to protect nor registers worth
touching, as opening it derives both limits from the MTU anyway, so
leave the hardware alone while it is down. That also keeps the warning
out of the boot log, where dsa_conduit_setup() sets the tagging overhead
on a conduit that carries no traffic yet.
Tested on an RTL9303 (Hasivo S1100W-8XGT-SE, RTL8264B PHY, USXGMII).
Both limits follow every MTU as computed, read back from the switch:
where the previous static sizing programmed 25 packets per ring at every
MTU. An MTU of 7175 is refused, and one of 9000, which the family
ceiling would allow, reaches the operation and is refused there: no
warning is logged for it, where an accepted change logs one, and the
boot log carries none at all. Raising the MTU to 1600 while the
interface is down leaves the registers at 1530 and the budget at 32
packets and logs nothing, while bringing it up afterwards programs 1626
and 25, so the change is deferred rather than lost. Traffic keeps
flowing across the changes: a 102 byte frame is answered five times out
of five at each step, while a 1046 byte one passes at MTU 1504, stops at
MTU 1000, whose limit of 1026 it exceeds, and passes again once the MTU
is back. Sixty alternating changes between two MTUs complete with
nothing logged, on a build with spinlock debugging enabled.
realtek: eth: bound the packet length at the CPU port
The length of the frames the switch may hand to the CPU has nothing to
do with the MTU the conduit runs at. The registers holding it keep
whatever the bootloader left, and the only other mechanism in the path
is the DMA truncation length, which does not drop what exceeds it: it
cuts the frame short and hands the remains to the stack. Nothing in the
target programs either of them from the MTU.
Add a per SoC set_max_packet_length() that programs those registers from
the conduit MTU and turns the truncation off, so an oversized frame is
dropped rather than delivered mutilated. The registers differ per
family, from the maps at svanheule.net, and every length field is 14
bits wide:
Longan is the only family whose CPU register carries a single field,
covering what the switch sends towards the CPU. What it takes from the
CPU lives in the port register of that port, 0x326c + port * 64, whose
two fields hold the length for the slow and the fast link speeds. The
vendor SDK reads the slow one there; both are programmed, as the driver
does not know at which speed the internal port runs. Mango keeps its
port registers in an array documented for ports 0 to 55, one short of
its CPU port, so there the CPU register alone holds both directions.
Characterised on an RTL9303 (Hasivo S1100W-8XGT-SE) by lowering the
truncation length and the maximum length of the CPU port in turn, while
frames of growing size were sent into a user port. The largest frame
that survives is the maximum length minus four, and the truncation
length minus eight, both constant at three settings of each register.
Beyond that boundary the truncation delivers a frame cut short, seen on
the conduit as 992 bytes where 1014 were sent, while the maximum length
register lets nothing through.
Read at the U-Boot prompt on the same board, reproduced across two
boots, the bootloader leaves 0xa3a0 at 0x600, 0x396c at 0x0c003000 and
DMA_IF_CTRL at 0x06400000, a truncation length of 1600 with every enable
still clear. With this patch and the conduit at its idle MTU of 1504,
both length registers read 1530, while DMA_IF_CTRL has its truncation
bit clear and the transmit and receive enables set.
Compile-tested only on RTL838x/839x/931x, where the offsets come from
the maps alone and the effect has not been observed. This changes what
those boards do at every interface open, not only when the MTU changes,
so testing from their owners is welcome. On RTL838x the transmit length
lives in a register of its own:
https://svanheule.net/realtek/maple/register/dma_if_pkt_tx_fltr_ctrl
Georgi Valkov [Sun, 12 Jul 2026 20:14:57 +0000 (23:14 +0300)]
mac80211: mwifiex: fix freeze for 60 seconds caused by request_firmware
Fix regression in rgpower table loading, caused by using
request_firmware(): when the requested firmware does not exist, e.g.
nxp/rgpower_WW.bin does not exist on OpenWrt builds for WRT3200ACM,
request_firmware() falls back to firmware_fallback_sysfs(), which expects
the firmware to be provided by user space using SYSFS. No such utility is
provided in this configuration, so the entire system locks up for 60
seconds, until the request times out. During this time, no other log
messages are observed, and the device does not respond to commands over
UART.
The request_firmware() call is performed in the following context:
current->comm kworker/1:2 in_task 1 irqs_disabled 0 in_atomic 0
Fixed by using request_firmware_direct(). This prevents fallback to SYSFS,
and avoids delay. The rgpower table is optional. The driver falls back
to the device tree power table if the firmware is not present.
The error code is printed for debugging and returned to the caller,
which only cares for success or failure, so there are no side effects.
Link: #24205 Fixes: #24434 Fixes: https://forum.openwrt.org/t/25-12-0-slow-boot-on-linksys-wrt3200acm/247751 Fixes: https://github.com/torvalds/linux/commit/7b6f16a258065f85793fb2597a290041c1e3d201 Signed-off-by: Georgi Valkov <gvalkov@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24205 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The board enables gdm1 in its DTS, but U-Boot v2026.07 ships
arch/arm/dts/an7581-u-boot.dtsi, which is appended to the end of the
board DTS and declares gdm1 with status = "disabled". The board setting
is overridden and U-Boot ends up without a network device.
Add a board specific an7581-w1700k-ubi-u-boot.dtsi re-enabling gdm1.
U-Boot only pulls in the first matching *-u-boot.dtsi (firstword in
scripts/Makefile.lib), so the board file must include the SoC one
explicitly, otherwise the entire an7581 U-Boot glue is dropped along
with it: uart1 bootph-all, the eth/pcs/snfi/mmc nodes and the ATF
reserved memory.
This is the same fix that was confirmed to restore networking on the
Nokia XG-040G-MD. It is compile tested only and verified by inspecting
the generated DTB - I have no W1700K hardware, so it is unverified on
the actual device and needs testing by someone who has one.
Fixes: baeacca59889 ("uboot-airoha: update to v2026.07") Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24410 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
U-Boot v2026.07 ships arch/arm/dts/an7581-u-boot.dtsi, which declares
gdm1 with status = "disabled". That file is appended to the end of the
board DTS, so it overrides the MAC enabled by the board and U-Boot ends
up without a network device:
No ethernet found.
Add a board specific an7581-nokia-xg-040g-md-u-boot.dtsi re-enabling
gdm1. U-Boot only pulls in the first matching *-u-boot.dtsi (firstword
in scripts/Makefile.lib), so the board file must include the SoC one
explicitly, otherwise the entire an7581 U-Boot glue is dropped along
with it: uart1 bootph-all, the eth/pcs/snfi/mmc nodes and the ATF
reserved memory. Same approach as en7581-evb and Nokia Valyrian.
Tested on Nokia XG-040G-MD: TFTP recovery boot works again.
Fixes: baeacca59889 ("uboot-airoha: update to v2026.07") Closes: https://github.com/openwrt/openwrt/issues/24385 Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24410 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
scripts: dl_github_archive: fix zstd args passed to tar
The multi-word zstd option '-I zstd -T0 --ultra -20' was appended as a
single argv element. subprocess passes each list element as one argv
entry, so tar received the whole string as one argument and failed to
recognize it. Split into separate '-I' and 'zstd -T0 --ultra -20'
elements so tar correctly interprets the compressor command.
projects / thirdparty / openwrt.git / log
