Shiji Yang [Sat, 2 May 2026 06:36:05 +0000 (14:36 +0800)]
toolchain: gcc: drop 110-Fix-MIPS-PR-84790.patch
The issue reported on the patch has been fixed in GCC 13.4.0[1],
14.2.0[2] and 15.1.0[3]. And we have already removed the GCC 14
patch variant in commit a1b9c28edd72 ("toolchain: gcc: drop 110-Fix-MIPS-PR-84790.patch").
1. Boot WRC-X6000GSD in router mode normally
2. Access to the WebUI ("http://192.168.2.1/") on the device
-> その他設定 (Other settings)
-> フォームウェア更新 (Update firmware)
-> ローカルファイル指定 (Specify local file)
3. Select the OpenWrt factory.bin image and click apply ("適用") button
4. Wait ~120 seconds to complete flashing
Switching to the stock firmware:
1. Load the elecom.sh script
. /lib/upgrade/elecom.sh
2. Check the current index of firmware partition
mstc_rw_bootnum
3. Set the bootnum to opposite value between 1 and 2
mstc_rw_bootnum value
example:
- step2 returned "1": mstc_rw_bootnum 2
- step2 returned "2": mstc_rw_bootnum 1
4. Reboot, to stock FW
5. Flash the stock FW to fuly revert back to original.
Notes:
- With the stock firmware, it will flash to another partition and
toggle boot to that partition when any firmware is flashed.
For example when booting on ubi, the new firmware will be flashed
to ubi_2 and the router will boot from ubi_2 afterwards.
The 5th byte of the Persist partition is the boot value (0x01 or 0x02).
- bootmenu_delay=0 is set from factory so uboot menu is hidden by
default.
- The hardware of WRC-X6000GSD is almost identical to WRC-X6000QS, but
WAN (labeled as "INTERNET") port is limited to 1000 Mbps on stock FW.
On OpenWrt FW, 2500 Mbps connection is available on that port.
MAC Addresses:
LAN : 38:97:A4:xx:xx:58 (Factory, 0x2A(hex)/Ubootenv, "ethaddr"(text))
WAN : 38:97:A4:xx:xx:5B (Factory, 0x24(hex))
2.4GHz: 38:97:A4:xx:xx:59 (Factory, 0x4(hex))
5GHz : 38:97:A4:xx:xx:5A (Factory, 0xA(hex)
1. Boot WRC-X6000QS in router mode normally
2. Access to the WebUI ("http://192.168.2.1/") on the device
-> その他設定 (Other settings)
-> フォームウェア更新 (Update firmware)
-> ローカルファイル指定 (Specify local file)
3. Select the OpenWrt factory.bin image and click apply ("適用") button
4. Wait ~120 seconds to complete flashing
Switching to the stock firmware:
1. Load the elecom.sh script
. /lib/upgrade/elecom.sh
2. Check the current index of firmware partition
mstc_rw_bootnum
3. Set the bootnum to opposite value between 1 and 2
mstc_rw_bootnum value
example:
- step2 returned "1": mstc_rw_bootnum 2
- step2 returned "2": mstc_rw_bootnum 1
4. Reboot, to stock FW
5. Flash the stock FW to fuly revert back to original.
Note 1: With the stock firmware, it will flash to another partition and
toggle boot to that partition when any firmware is flashed.
For example when booting on ubi, the new firmware will be flashed
to ubi_2 and the router will boot from ubi_2 afterwards.
The 5th byte of the Persist partition is the boot value (0x01 or 0x02).
During my tests, it never switched to another boot partition if the
firmware failed boot. So if openwrt doesn't boot,
UART might be required to recover.
Note 2: bootmenu_delay=0 is set from factory so uboot menu is hidden.
iw: backport scan print of RSN Element Override IEs
Backport upstream iw commit d90618809e06 ("iw: scan: print RSN
Element Override IEs") as 001-*.patch so `iw scan` decodes the
RSNOE (vendor WFA type 41) and RSNO2E (type 42) elements that
hostapd emits for WPA3 Compatibility / RSN Overriding APs.
Also refresh the hunk offsets in 200-reduce_size.patch.
Two of the IW_FULL guards in 200-reduce_size.patch were inverted
or incomplete:
* the "unknown event" handler unconditionally replaced the
verbose print with the short form, so IW_FULL builds lost
the command name decoding;
* the early return before the vendor IE parser used
#ifdef IW_FULL, which suppressed parsing in the full build
instead of the size-reduced one.
Wrap both with the correct #ifndef IW_FULL / #else so the full
and reduced builds produce the intended output.
wifi-scripts: ucode: default sae_groups to NIST ECP 19/20/21
The WPA3 and Wi-Fi Enhanced Open Deployment Guide v1.1 (Table 4,
"SAE Groups") recommends that WPA3-Personal APs advertise support
for SAE groups 19, 20 and 21:
* group 19 - ECP 256-bit (NIST P-256)
* group 20 - ECP 384-bit (NIST P-384)
* group 21 - ECP 521-bit (NIST P-521)
hostapd's default is group 19 only, which leaves the two larger
ECP groups unavailable even though the peer may prefer them.
Set sae_groups = "19 20 21" as the default for any BSS whose
auth_type is sae or psk-sae (SAE, SAE Transition and SAE
Compatibility modes).
wifi-scripts: ucode: default BIP cipher from wpa_pairwise
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1 (Tables 4, 5, 6) requires the group-management cipher (BIP) to
match the mode and strength of the pairwise cipher: GCM-mode pairwise
ciphers pair with BIP-GMAC integrity, CCM-mode pairwise ciphers with
BIP-CMAC integrity. The ucode pipeline hard-coded group_mgmt_cipher
to AES-128-CMAC (BIP-CMAC-128) regardless of the pairwise cipher,
except for the eap192 special case that already forced BIP-GMAC-256.
An EHT WPA3-Personal BSS therefore emitted wpa_pairwise=GCMP-256
alongside group_mgmt_cipher=AES-128-CMAC -- the integrity cipher two
steps weaker than the data cipher and a spec violation on EHT.
hostapd has a single group_mgmt_cipher knob, so the selected BIP has
to be compatible with every pairwise cipher in wpa_pairwise. Picking
from the first token would mis-select on mixed lists -- e.g.
wpa_pairwise=\"GCMP-256 CCMP\" would yield BIP-GMAC-256, which a
CCMP-only STA cannot negotiate.
Walk the wpa_pairwise tokens and pick the BIP that matches the
weakest cipher present:
Token matching uses fnmatch wildcards against a copy of wpa_pairwise
that is padded with leading and trailing spaces, so each token is
space-bounded regardless of its position in the list.
The RSN override pairwise lists are not consulted: in the only
caller that sets them (WPA3-Personal Compatibility Mode), Tables 6
and 7 require BIP-CMAC-128 across RSNE/RSNOE/RSNO2E even when the
override lists advertise GCMP-256, so wpa_pairwise=CCMP already
yields the correct BIP.
An explicit ieee80211w_mgmt_cipher UCI value still wins over the
derived default.
wifi-scripts: ucode: advertise Transition Disable on WPA3-only BSSes
WPA3 Specification v3.5 §13 defines the Transition Disable element sent
inside message 3 of the 4-way handshake. An AP that is no longer
offering a transition mode for its SSID sets the matching bit so that
compliant STAs permanently stop falling back to WPA-PSK / WPA-EAP /
open for that SSID, hardening against downgrade attacks and against
operator mistakes where a transition-mode BSS is briefly brought up on
an SSID that previously ran WPA3-only.
Expose this as a UCI list 'transition_disable' with three classes of
entries:
* The existing OpenWrt encryption tokens 'sae' (bit 0x01), 'sae-pk'
(0x02), 'wpa3' (0x04) and 'owe' (0x08) OR into the bitmap. SAE-PK
itself is not yet wired through wifi-scripts; the token only lets
an operator who configured SAE-PK out of band also hand the
matching bit to hostapd.
* 'on' derives the bitmap from the AP's auth_type ('sae' -> 0x01,
'eap2'/'eap192' -> 0x04, pure 'owe' -> 0x08) and overrides any
other explicit tokens in the same list. Transition BSSes
(psk-sae, eap-eap2, owe with owe_transition set) produce no
bits even under 'on' because they are by definition still in
transition.
* 'off' unconditionally suppresses the element regardless of any
other entries. Operators who need to revert a WPA3-only SSID back
to a transition mode can set this proactively, giving compliant
STAs time to forget the permanent bit before the mode change.
Leave the list unset by default. Advertising Transition Disable is a
one-way door -- once a compliant STA has seen the permanent bit for an
SSID it will refuse to associate to a transition-mode BSS of the same
name ever again -- so it must be opted in to per SSID, never flipped
on by a firmware bump. This also matches the WPA3 and Wi-Fi Enhanced
Open Deployment and Implementation Guide v1.1 Table 4 requirement that
Transition Disable be MAND disabled by default on APs.
wifi-scripts: ucode: default sae_pwe to H2E-only on 6 GHz
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1 (Tables 7 and 8) mandates "H2E Only" for SAE on 6 GHz, in both
WPA3-Personal Only and WPA3-Personal Compatibility Mode: the 6 GHz
band disallows the legacy Hunting-and-Pecking password element, so
the AP must advertise BSS Membership Selector 123 to force STAs onto
H2E.
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1 §2.4 (Tables 6 and 7) defines WPA3-Personal Compatibility Mode:
the AP advertises a legacy-looking RSNE (WPA-PSK, CCMP-128, PMF
Disabled) while RSN Override Elements layered on top expose SAE and,
on EHT, SAE-EXT-KEY. WPA2-only STAs and STAs that ignore RSN
Overriding associate unchanged; modern STAs pick up the stronger WPA3
AKM via RSNOE or RSNO2E.
Only the pairwise cipher differs between elements: RSNE and RSNOE
advertise CCMP-128, RSNO2E advertises GCMP-256 (EHT only). Group
data (CCMP-128) and group management cipher (BIP-CMAC-128) are the
same in all three per Tables 6/7, so hostapd's BSS-wide group_cipher
and group_mgmt_cipher singletons produce the spec-correct values.
Unlike WPA3-Personal Transition Mode (sae-mixed), which puts PSK and
SAE together in the main RSNE with PMF Capable, Compatibility Mode
keeps the main RSNE strictly WPA2-shaped so clients that choke on a
mixed AKM list or PMF=Capable still see a pure WPA2 BSS. The trade-
off is that clients without RSN Overriding support never pick up SAE.
wifi-scripts: ucode: enable Beacon Protection by default with PMF
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1, Table 4 (Common security configuration) marks Beacon Protection
as MAND for EHT-enabled APs and RECOM otherwise for all WPA3 and
Wi-Fi Enhanced Open modes.
The ucode path blindly passed beacon_prot through from UCI in iface
setup, which ran before encryption and MFP had been configured, and
left hostapd at its insecure default of 0 when the user did not
explicitly opt in.
Default beacon_prot to 1 in iface_mfp after MFP has been confirmed to
be enabled, and emit it there instead of in iface_setup so the option
is only written when PMF support is actually negotiated. Users can
still disable it explicitly via UCI.
WPA3 Specification v3.5 §2.5.4 mandates that an AP's BSS Configuration
enables AKM suite selector 00-0F-AC:24 (SAE-EXT-KEY, SAE with a
group-dependent hash) whenever EHT or MLO is enabled. The WPA3 and
Wi-Fi Enhanced Open Deployment Guide v1.1 also recommends it on
non-EHT APs (Tables 3, 5, 6, 8).
Add a new sae_ext_key UCI option (enabled by default) that advertises
SAE-EXT-KEY, and FT-SAE-EXT-KEY when 802.11r is enabled, alongside
plain SAE/FT-SAE for the sae and psk-sae encryption modes.
parse_encryption() stashed a preliminary wpa_pairwise value in a
local wpa3_pairwise variable, cleared it per auth_type, then let a
switch default either copy it back or special-case wpa3-192. The
result was three separate places where wpa_pairwise was clobbered
and behavior that was awkward to trace when the explicit cipher
suffix (encryption[1]) and the auth_type disagreed.
Replace the scaffolding with a single block at the end of
parse_encryption() that only assigns wpa_pairwise via ??= when no
earlier branch (explicit cipher suffix, wpa3-192, or sae-compat)
has already set one:
no WPA -> null
60 GHz (hw_mode=ad) -> GCMP
HE or EHT htmode -> GCMP-256 CCMP
everything else -> CCMP
wpa3-192 now sets wpa_pairwise='GCMP-256' directly in its switch
case, so the final default block can stay short. No functional
change for existing encryption values.
wifi-scripts: ucode: drop the generic rsn_override UCI knob
The rsn_override UCI number was scaffolding that let a Transition
Mode BSS (sae-mixed, wpa3-mixed) automatically overlay a WPA3
Compatibility-Mode-like layout: WPA3 AKMs were moved from the main
RSNE into RSNOE/RSNO2E, and with rsn_override=2 the main RSNE even
dropped SAE entirely to placate clients that refuse to associate to
a mixed AKM list.
This layout does not match any mode defined in the WPA3 and Wi-Fi
Enhanced Open Deployment and Implementation Guide v1.1: Transition
Mode (Table 5) advertises the full AKM list in a single RSNE, and
Compatibility Mode (§2.4, Tables 6 and 7) requires a specific
combination of RSNE, RSNOE and RSNO2E contents that the knob cannot
express. In practice it also triggers interop failures: Pixel 10
phones refuse to associate to a Transition-Mode BSS whose SAE-EXT-KEY
AKM has been shoved into RSNO2E by this scaffolding, even though the
same BSS works fine when the full AKM list stays in the main RSNE.
Keep the generated configuration honest by removing the knob; the RSN
override plumbing stays in place for a future caller that sets the
override fields explicitly. SAE-EXT-KEY advertisement will be added
back in a later commit via a dedicated sae_ext_key path that places
the AKM where the Deployment Guide actually requires it.
Drop the rsn_override schema entry and every wifi-scripts path that
read it:
* parse_encryption no longer diverts the WPA3 pairwise cipher
into rsn_override_pairwise.
* wpa_key_mgmt no longer mirrors WPA-EAP into
rsn_override_key_mgmt, moves SAE/SAE-EXT-KEY into the override
for psk-sae, or drops the main RSNE AKM list when
rsn_override > 1.
* generate() no longer back-fills missing rsn_override_* fields
from the main RSNE or duplicates the override element into an
MLO-gated RSNO2E.
The RSN override elements are now emitted only when each of
(rsn_override_key_mgmt, rsn_override_pairwise, rsn_override_mfp) --
and their _2 counterparts -- has been populated explicitly, which
keeps the machinery from firing on transition modes where it was
never spec-compliant.
Fixes: https://github.com/openwrt/openwrt/issues/21486 Fixes: https://github.com/openwrt/openwrt/issues/22200 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: https://github.com/openwrt/openwrt/pull/23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
wifi-scripts: ucode: do not leak SAE options onto non-SAE BSSes
sae_require_mfp and sae_pwe are SAE-specific knobs but iface_auth_type()
set them on every auth type that requires PMF (sae, owe, eap2, eap192,
dpp) and on both PMF-optional transition modes (psk-sae, eap-eap2).
hostapd silently ignores the stray settings on non-SAE BSSes, but they
clutter the generated configuration and make it harder to tell at a
glance which knobs actually apply.
Split the grouping: keep ieee80211w (and rsn_override_mfp for transition
modes) where it was, and move sae_require_mfp / sae_pwe into a separate
check that only fires for the two auth types that actually run SAE (sae
and psk-sae).
Hauke Mehrtens [Fri, 1 May 2026 16:02:22 +0000 (18:02 +0200)]
github: extend LLM review rules with three new categories
Tightened from real bot reviews:
- Patch regeneration: spell out which make ... refresh command
to recommend for each patch directory class, so the bot stops
suggesting git format-patch for quilt-managed patches.
- Backports / cherry-picks: a backport's diff should match the
upstream commit on main verbatim; flag only deviations and
the missing (cherry picked from commit <sha>) trailer, not
pre-existing style issues.
- New device support: require Hardware specification, Flash
instructions, and MAC address layout sections in the commit
message that introduces a new device. Two reference commits
(986ca4c887f4, a2dcbd79a446) named so the bot can sample the
expected shape.
Drop-in wrapper that calls the reusable LLM review workflows in
openwrt/actions-shared-workflows. Triggers on pull_request_target
(incl. PRs from forks), a nightly cron (03:00 UTC), and manual
workflow_dispatch with a max_prs input override.
A detect-kernels pre-step builds the extra_repos list at workflow
runtime: it reads target/linux/generic/kernel-* in the base branch
to derive gregkh/linux:v<X.Y.Z> tags for each currently-targeted
kernel, then appends u-boot/u-boot:master. The list updates
automatically when kernel versions are bumped; the routine clones
only the entries actually needed for a given diff.
The bundled .github/llm-review-rules.md teaches the bot two
project-specific deprecations to flag even when other in-tree files
still use the legacy form:
- LED label syntax `label = "<color>:<function>";` -->
`color = <LED_COLOR_ID_*>;` + `function = "<func>";`
- `mediatek,mtd-eeprom` for MAC sourcing -->
`nvmem-cells` + `nvmem-cell-names = "mac-address";`
Repository settings need LLM_ROUTINE_ID_PR / LLM_ROUTINE_TOKEN_PR
and the *_NIGHTLY counterparts populated before the workflow can
fire. See openwrt/actions-shared-workflows/docs/llm-review-setup.md
for the full setup procedure.
realtek: mdio: convert to generic regmap_bulk_write()
Each architecture has its own SMI address and SMI data size. Make the
current device specific coding generic by
- adding SMI start address and SMI data size to configuration structure
- moving regmap_bulk_write() over to the generic rtmdio_run_cmd()
- deleting all device specific rtmdio_xxxx_run_cmd() versions
Each target has a specific SMI register where the result of read
commands is stored. As the read logic is always the same convert
the current logic to a generic one. Instead of a target specific
coding move eveything into the configuration structure and let
rtmdio_run_cmd() do the work.
realtek: mdio: move command data into config structure
Until now the device specific I/O helpers are instrumented by individual
call parameters. Move this information over to the configuration structure.
This simplifies the code at the calling locations.
realtek: mdio: use regmap_bulk_write() in RTL931x path
Convert the RTL931x I/O path to the new bulk write pattern. For this
- Enhance the rtmdio_931x_run_cmd() helper to take care of all register
access and error handling.
- Convert the c22/c45/read/write functions so that they only prepare
the I/O data without any register access.
realtek: mdio: use regmap_bulk_write() in RTL930x path
Convert the RTL930x I/O path to the new bulk write pattern. For this
- Enhance the rtmdio_930x_run_cmd() helper to take care of all register
access and error handling.
- Convert the c22/c45/read/write functions so that they only prepare
the I/O data without any register access.
realtek: mdio: use regmap_bulk_write() in RTL839x path
Convert the RTL839x I/O path to the new bulk write pattern. For this
- Enhance the rtmdio_839x_run_cmd() helper to take care of all register
access and error handling.
- Convert the c22/c45/read/write functions so that they only prepare
the I/O data without any register access.
realtek: mdio: use regmap_bulk_write() in RTL838x path
The regmap conversion only replaced the old sw() macros with their
regmap counterparts. Neither access optimization nor error handling
took place. Redesign the mdio access as follows:
- The c22/c45/read/write functions only prepare a data structure
that describes the to-be-executed command.
- rtmdio_xxxx_run_cmd() is enhanced to bulk write the data into the
SoC, issue all the I/O and do proper error handling. Additionally
the signature is changed to allow read & write operations.
The bulk commands introduce some subtle changes.
- Before this patch only the needed registers were written. After
the conversion all phy control registers are set up.
- The register write order changes
This is no issue as the hardware starts operation when issuing the
run_cmd() and only accesses the needed registers per operation.
For now adapt only the RTL838x path. Where needed rename "err" to
"ret" for consistency with kernel conventions.
Power
Mesh (RGB Led, user controllable, default set to OpenWrt Status)
WLAN 2.4G (user controllable)
WAN (user controllable)
LAN3
LAN2
LAN1
WLAN 5G (user controllable)
Installation:
A. Through U-Boot menu:
- Prepare your connecting computer to use static IP
(legacy notation) 192.168.1.10 netmask 255.255.255.0
(CIDR notation) 192.168.1.10/24
- Power down the router and hold in the Reset button.
- While holding in the button power up the router again.
- Hold the button in for 10 seconds and then release.
- Use your browser to go to 192.168.1.1
- If you see a GUI allowing for flashing firmware you are at the right spot.
- Upload the **Factory** image file.
Note: U-Boot GUI it can be used to recover from an incorrect firmware flash.
B. Through OpenWrt Dashboard:
If your router comes with OpenWrt preinstalled (modified by the seller),
you can easily upgrade by going to the dashboard (192.168.1.1)
and then navigate to
System -> Backup/Flash firmware, then flash the firmware
Shiji Yang [Tue, 28 Apr 2026 13:06:36 +0000 (21:06 +0800)]
ramips: mt7621: disable CONFIG_PAGE_POOL_STATS
Commit 15887235c1e3 ("generic: mtk_eth_soc: reduce driver memory usage")
allows building mediatek ethernet driver without CONFIG_PAGE_POOL_STATS.
This can slightly improve throughput on legacy MIPS based MT7621 SoC.
xiao bo [Sun, 26 Apr 2026 20:40:13 +0000 (04:40 +0800)]
wireless-regdb: update to version 2026.03.18
Changes:
update regulatory database based on preceding
Update regulatory rules for India (IN) on 6GHz
Replace M2Crypto with cryptography package
Fix regulatory.bin signing with new
* Update Mozilla certificate authority bundle to version 2.82
The following certificate authorities were added (+):
+ TrustAsia TLS ECC Root CA
+ TrustAsia TLS RSA Root CA
+ SwissSign RSA TLS Root CA 2022 - 1
+ OISTE Server Root ECC G1
+ OISTE Server Root RSA G1
The following certificate authorities were removed (-):
- GlobalSign Root CA
- Entrust.net Premium 2048 Secure Server CA
- Baltimore CyberTrust Root (closes: #1121936)
- Comodo AAA Services root
- XRamp Global CA Root
- Go Daddy Class 2 CA
- Starfield Class 2 CA
- CommScope Public Trust ECC Root-01
- CommScope Public Trust ECC Root-02
- CommScope Public Trust RSA Root-01
- CommScope Public Trust RSA Root-02
* Use dh_usrlocal to create /usr/local/share/ca-certificates
(closes: #1127100)
Now that the stp_set() helpers have been refactored the stp_get()
helpers can be simplified. Drop the last array parameter. It is
no longer needed/evaluated by its callers.
realtek: dsa: remove family_id check from xstp_state_set()
The rtldsa_port_xstp_state_set() function offers a generic interface
to its callers to set the bridge state of one port. While it calls
device specific helpers in the background it runs the data mapping
for each architecture with a family_id check on its own. So the
hardware abstraction is done in two places
- rtldsa_port_xstp_state_set() translates one half
- its helper translate the other half
Convert the signature of the device specific helpers so that this
function does not need to know any hardware details. Instead move
the table/offset/bit calculations into the helpers. This way the
code path uses a consistent hardware abstraction.
- rtldsa_port_xstp_state_set() calls the helpers
- helpers do the hardware translation
Hannu Nyman [Sun, 26 Apr 2026 18:16:48 +0000 (21:16 +0300)]
sdk: add support to sign each .apk package by sdk
Add support to signing each package's .apk file into SDK.
This adds into SDK the feature added by f20794a to the normal builds.
Currently SDK does not sign the compiled packages, causing untrusted
package errors at package installation. The reason is the logic of
defaulting to 'n' in BUILDBOT and 'y' elsewhere. As downloadable SDKs
are compiled by the buildbot, the option gets 'n' set as the default.
And the option is not among the few build options exposed in the SDK
menuconfig, so the user can't easily change it.
Enable the feature by default:
* Exclude the SIGN_EACH_PACKAGE option from sdk/convert-config.pl
* Default to 'y' and expose the option in the SDK config menu.
(Avoiding untrusted errors naturally requires the user to copy the
public key into the router, quite similar as with full builds.)
Robert Marko [Wed, 29 Apr 2026 09:35:45 +0000 (11:35 +0200)]
microchipsw: fix LAN8814 QSGMII soft reset
Currently, moving from a port on one LAN8814 PHY package to another results
in a no traffic flowing on that new port.
It was tracked down to upstream change that fixed the issue that QSGMII
was soft reset on .config_init of each of 4 PHY-s in the package resulting
in a temporary traffic loss until QSGMII resynced.
However, it seems that the QSGMII soft reset timing is crucial and doing
the reset during probe only cause the QSGMII link to become partially
unsynced (Like 2 or 3 lanes are not synced).
So, add an upstream pending patch[1] to fix this, patch was modified as we
dont have the inband caps currently.
Ivan Romanov [Mon, 27 Apr 2026 13:43:53 +0000 (18:43 +0500)]
dropbear: require busybox pidof applet
The dropbear init script uses pidof, but BusyBox may be built
without it. Add a Kconfig dependency on BUSYBOX_CONFIG_PIDOF
to ensure the applet is available at runtime.
Ivan Romanov [Mon, 27 Apr 2026 16:32:57 +0000 (21:32 +0500)]
dnsmasq: require busybox pidof applet
The dnsmasq init script uses pidof, but BusyBox may be built
without it. Add a Kconfig dependency on BUSYBOX_CONFIG_PIDOF
to ensure the applet is available at runtime.
The Kconfig symbol help text prompts:
Disable this to get a possibly more secure configuration, but that
might not be backward compatible with previous kernels.
If backward compatibility is not an issue, then it is safe and
recommended to say N here.
For OpenWrt, when updating firmware, we always update the kernel and
recreate the overlay partition. Therefore, compatibility is not a
problem.
dropbear: don't spread conffiles across two packages
For some reason, /etc/config/dropbear is enumerated as a
conffile for dropbear packaging, but /etc/dropbear/ is
part of base-files packaging. If you're an openssh-server
user, then you don't have this directory on your router in
any case.
The nRESET pins of the RTL8224 PHY on the MCX3 are wired to GPIO6 of the
SoC, but this was never described in the devicetree.
Commit c99a30668d5f ("realtek: add RTL8224 initialization to Realtek
driver") introduced support for reinitializing RTL8224 PHYs, and commit 084da38a2e74 ("realtek: mdio: activate multiple busses") allowed the MDIO
bus provider load the devicetree properties to the bus, including reset
descriptors. With both in place, a bus level PHY reset via the hardware pin
is now correctly triggered before reinitialization.
Add the missing reset-gpios property so the PHY can be reset via the
hardware pin.
Remove legacy hack patch, switch mt7621 crypto node to the intended
Safexcel insecure EIP93 compatible string and simplify crypto module
packaging to use the inside-secure eip93 driver.
FIPS 140-3 recommends that all crypto implementations should be tested
before first use. Testmanager performs initial tests based on existing
test vectors. Not all algorithms have defined test vectors, so to improve
this situation, this commit backports recently added test vectors for
some cipher suites.
These vectors were calculated using a software implementation and then
double-checked on Mediatek MT7981 (safexcel) and NXP P2020 (talitos).
Both platforms passed self-tests.
realtek: arch: rtl-otto: add rtl9607 model info support
Add the registers, family id and cpu port defines to the mach header.
Since RTL96xx SoCs has additional "subtype" info, add the respective
property to soc_info struct to be used in prom file.
The same way as rtl838x, the chip_info register requires 0xa to be
written. Similarly, 0xb must be written to get the subtype info.
There doesn't seem any check for testchip in RTL96xx so, we ignore it.
Add subtype information to set_system_type function if it is present
using the added subtype variable.
There are some RTL9607 chips out there with 512MB so add the check
for RTL9607 in the prepare_highmem. The registers are the same as
in RTL9300 so nothing else need to be changed.
Add patches to improve support for using 3rd-party DSA switches
like MaxLinear MxL862xx with MediaTek's mtk_eth_soc being the
conduit. This involves reorganizing hardware queues to avoid
overlap (currently dp->index is used -- if there is more than one
DSA switch this is problematic), and correctly programming flows
of the non-MTK DSA users ports in the PPE offloading engine.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Paweł Owoc [Mon, 27 Apr 2026 11:57:28 +0000 (13:57 +0200)]
modules: video: Fix DRM client lib dependency
Fix dependency for kmod-drm-client-lib module:
error: recursive dependency detected!
symbol LINUX_6_18 is selected by PACKAGE_kmod-drm-client-lib
symbol PACKAGE_kmod-drm-client-lib is selected by LINUX_6_18
Fixes: e75ba35ed837 ("modules: video: introduce DRM client setup module") Signed-off-by: Paweł Owoc <frut3k7@gmail.com> Link: https://github.com/openwrt/openwrt/pull/23124 Signed-off-by: Robert Marko <robimarko@gmail.com>
Shiji Yang [Mon, 27 Apr 2026 11:42:55 +0000 (19:42 +0800)]
bcm27xx: update irq-msi-lib.h header path
Fix build error:
drivers/irqchip/irq-bcm2712-mip.c:14:10: fatal error: irq-msi-lib.h: No such file or directory
14 | #include "irq-msi-lib.h"
| ^~~~~~~~~~~~~~~
Fixes: ba7aa2a97153 ("generic: backport MSI affinity support for DW PCIe") Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/23125 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Thu, 23 Apr 2026 11:28:45 +0000 (11:28 +0000)]
realtek: pcs: rtl931x: drop USXGMII gating in setup_serdes
The USXGMII_10GDXGMII and USXGMII_10GQXGMII early-return was added
when the submode register was not yet programmed, making those modes
effectively unconfigurable. With the submode now wired up at probe
time and written from the set_mode path, the gating is no longer
needed.
Keep the XSGMII gate - RTL8218D/E bring-up through the proprietary
10G SGMII path is still unimplemented - and rewrite the surrounding
comment accordingly.
Complete the USXGMII submode table with the four values that were
missing so far:
0x01 10GDX (2 x 5G)
0x03 5GSX (1 x 5G)
0x04 5GDX (2 x 2.5G)
0x05 2_5GSX (1 x 2.5G)
Together with the existing 10GSX (0x00) and 10GQX (0x02) this covers
all six USXGMII modes the driver declares. Add a corresponding mapping
to the hw_mode table too to cover them properly there.
Replace the switch in rtpcs_93xx_sds_apply_usxgmii_submode() with a
sparse lookup table indexed by hw_mode, using -1 as the sentinel for
modes without a submode value. Non-USXGMII modes silently no-op as
before; a USXGMII mode hitting a SerDes without an allocated submode
register now returns -EOPNOTSUPP, catching configuration mismatches
that would previously have been silently dropped.
USXGMII submode (10GSX vs 10GQX) is selected through a dedicated
register at 0x13e8, independent of the MAC and IP mode registers.
Without programming it, USXGMII-QX ports initialise as single-lane
SX and fail to link up correctly; MAC and IP mode alone are
insufficient for a working USXGMII setup.
The register packs 12 x 5-bit entries for SerDes 2..13, six per
32-bit word, non-straddling (bits 0..29 used, 30..31 padded). This
matches the available register dumps and the SDK's
reg_array_field_write() non-CROSS_REGISTERS path, which derives the
bit position as ((index - larray) % (32 / width)) * width and
accesses only a single 32-bit word. The submode values are identical
to RTL930x, so the shared RTPCS_93XX_SDS_USXGMII_SUBMODE_* defines
are reused.
Allocate the regmap_field at probe time with coordinates computed
from the SerDes ID; the regular packing needs no lookup table. Call
rtpcs_93xx_sds_apply_usxgmii_submode() from the set_mode dispatcher
after set_ip_mode - the helper's null-guard and mode filter leave
non-USXGMII paths unchanged.
Its original commit message fails to mention that the commit also moves
the `#include <memory>` to an earlier position within system.h,
which is the actual change that we're after in this patch.
Building our GCC 14.3 with host GCC 16, the inclusion order starts to matter,
which is an issue that was also touched upon by the upstream commits:
9970b576b7e4 Include safe-ctype.h after C++ standard headers, to avoid over-poisoning f6e00226a4ca build: Move sstream include above safe-ctype.h {PR117771]
Sven Eckelmann [Tue, 7 Apr 2026 07:14:25 +0000 (09:14 +0200)]
realtek: dsa: postpone probe due to deferred PHYs
PHY drivers might need access to NVMEM or the filesystem to load
calibration/initialization data. The driver will then return -EPROBE_DEFER
to signal to the device core that the probe should be retried multiple
times again in the 10s driver_deferred_probe_timeout.
But when the switch driver calls dsa_register_switch(), it needs to connect
the PHYs directly. As result, all PHYs without an driver will automatically
get the default driver (either `genphy_c45_driver` or `genphy_driver`)
assigned and initialized. But for PHYs with the additional initialization
data from NVMEM/fs, this will usually result in not working PHYs.
Since there are Realtek based boards with RTL826x PHYs and the new driver
loads the initialization/patch values from rootfs, it is necessary to check
in the beginning of the probe function whether the PHYs are ready and the
probing can continue.
If some driver is still without driver after the deferred probe period
ended, the loading will just continue and the generic PHY drivers will
still be used.
Closes: #22811 Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com> Co-authored-by: Markus Stockhausen <markus.stockhausen@gmx.de> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/23075 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Wed, 22 Apr 2026 07:39:58 +0000 (07:39 +0000)]
realtek: pcs: rtl93xx: add shared MAC mode wrapper
RTL930x and RTL931x share a set of extras around MAC mode writes:
- a post-write delay (kept for consistency with the original RTL930x
behaviour; harmless on RTL931x)
- the force-mode bit (RTL931x only, nullable field)
Add rtpcs_93xx_sds_set_mac_mode() as a shared wrapper around the
generic rtpcs_sds_set_mac_mode() that applies each of these extras
unconditionally; the nullable field makes the force-bit write a no-op
on RTL930x.
Route the three RTL93xx call sites (the 930x and 931x set_mode
dispatchers, and 931x set_ip_mode's OFF transition) through the
wrapper, removing the duplicated force-bit handling from each.
The USXGMII submode write stays out of the wrapper and is called
explicitly from the 930x dispatcher via rtpcs_93xx_sds_apply_usxgmii_submode().
Keeping submode as a separate step leaves room for RTL931x to apply it
from its IP-mode path once the submode register is wired up, without
retrofitting a MAC-mode wrapper with side effects.
Jonas Jelonek [Mon, 20 Apr 2026 20:26:12 +0000 (20:26 +0000)]
realtek: pcs: rtl931x: migrate MAC mode setting to regmap_field
RTL931x uses a regular 8-bit-per-SerDes layout in SERDES_MODE_CTRL, so
the reg_field can be computed in the probe hook with simple arithmetic.
The 8-bit-per-SerDes field is split into a 7-bit mac_mode (bits 0..6)
and a 1-bit mac_mode_force (bit 7), each written independently via its
own regmap_field. The mac_mode is widened to 7 bits (rather than the
5 bits strictly needed for the mode value) so MAC mode writes also
clear bit 5 (FEC enable) and bit 6 (10G speedup), matching the original
behaviour where the full 8-bit mask cleared these bits on every mode
change. FEC and speedup are mode-dependent and not yet programmed by
the driver; keeping them cleared leaves headroom for future support
without changing the effective register value.
rtpcs_931x_sds_reset() is updated to save and restore both fields
across the off/on cycle, preserving the original force-bit handling.
rtpcs_931x_sds_set_mode() uses the generic rtpcs_sds_set_mac_mode() and
sets the force bit explicitly; the same sequence also appears in
rtpcs_931x_sds_set_ip_mode()'s OFF transition. Both are folded into
the shared RTL93xx wrapper in a later commit.
Jonas Jelonek [Mon, 20 Apr 2026 20:15:46 +0000 (20:15 +0000)]
realtek: pcs: rtl930x: migrate MAC mode setting to regmap_field
RTL930x packs 5-bit mode fields across four registers at irregular
positions. Express this as a static reg_field table indexed by SerDes
ID; the probe hook allocates the corresponding regmap_field. The
USXGMII submode register follows the same pattern with its own
reg_field table, allocated only for 10G-capable SerDes (id 2..9).
The generic rtpcs_sds_set_mac_mode() replaces the old
__rtpcs_930x_sds_set_mac_mode() helper. The previous behaviour of
writing OFF before the target mode is intentionally dropped — it was
RTL930x-specific and not required by the hardware.
The variant-level rtpcs_930x_sds_set_mode() is kept as a pure dispatch
between the IP mode path (set_ip_mode) and the MAC mode path. The
USXGMII submode write is factored into rtpcs_93xx_sds_apply_usxgmii_submode(),
which derives the submode value from hw_mode and no-ops on SerDes
without the submode register.
The __rtpcs_930x_sds_get_mac_mode() and __rtpcs_930x_sds_get_usxgmii_submode()
helpers are dropped. They were __always_unused and depended on the
removed parallel arrays. A future get_mode path will be added if a
caller needs it, likely mirroring the setter's wrapper shape.
Jonas Jelonek [Mon, 20 Apr 2026 19:43:05 +0000 (19:43 +0000)]
realtek: pcs: rtl839x: migrate MAC mode setting to regmap_field
RTL839x packs the SerDes MAC mode in MAC_SERDES_IF_CTRL with a regular
per-SerDes layout, so the regmap_field can be computed directly in the
probe hook rather than declared as a static table.
Mode values (currently only OFF and QSGMII) move into a static
rtpcs_839x_sds_hw_mode_vals[] table. Values for 100BASEX, 1000BASEX
and SGMII from the vendor SDK are kept as comments for future
reference — they are not yet exercised here.
With no variant-specific extras (no force bit, no companion register,
no submode), rtpcs_839x_sds_set_mode() is removed; setup_serdes calls
the generic rtpcs_sds_set_mac_mode() directly.
Jonas Jelonek [Mon, 20 Apr 2026 19:35:13 +0000 (19:35 +0000)]
realtek: pcs: rtl838x: migrate MAC mode setting to regmap_field
Replace rtpcs_838x_sds_set_mode()'s inline shift/mask arithmetic with
a regmap_field computed and allocated at probe time. The field layout
is regular (5-bit per SerDes, reverse-packed in SDS_MODE_SEL), so the
position can be derived arithmetically from the SerDes ID rather than
declared in a table.
The function keeps its wrapper role because SerDes 4 and 5 have a
second companion register (INT_MODE_CTRL) with its own per-mode value
encoding. Since RTL838x is the only variant with this quirk and the
register is written from only one call site, it is kept inline rather
than abstracted into its own config table.
Jonas Jelonek [Mon, 20 Apr 2026 19:20:49 +0000 (19:20 +0000)]
realtek: pcs: add regmap-based MAC mode infrastructure
All four Realtek PCS variants (RTL838x, RTL839x, RTL930x, RTL931x)
configure the SerDes MAC mode by writing a register field whose layout
varies per variant — different base registers, different bit positions,
and in some cases per-SerDes packing that isn't arithmetically regular.
Add the common infrastructure to express this uniformly:
- per-SerDes regmap_field pointers in a new 'swcore_regs' anonymous
struct on rtpcs_serdes: mac_mode, mac_mode_force (931x only, nullable)
and usxgmii_submode (930x only, nullable).
- a per-variant mode-value table pointer (sds_hw_mode_vals) on
rtpcs_config, keyed by enum rtpcs_sds_mode. Values are s16 with -1 as
the "unsupported" sentinel — u8 with 0 would collide with RTL839x's
OFF value (0x0).
- a generic rtpcs_sds_set_mac_mode() that looks up the value for the
requested mode and writes it via the regmap_field.
Variant-specific extras (post-write delay, force bit, companion register
writes, USXGMII submode handling) will be added in per-variant wrappers
in the following commits.
Pawel Dembicki [Sat, 28 Mar 2026 22:39:16 +0000 (23:39 +0100)]
kernel/kirkwood: 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
projects / thirdparty / openwrt.git / log
