The CPPE buffer manager TDM table contains 98 entries, while the
SSDK cppe_port_tdm0_tbl has 96. The first 96 entries match exactly; the
trailing CPU ingress and egress pair duplicates the beginning of the
circular schedule and makes ARRAY_SIZE program a depth of 98.
Drop the duplicate pair so the schedule and depth match SSDK.
Link: https://github.com/openwrt/openwrt/pull/24203#issuecomment-5446469623
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport the EN7528 pin controller, accepted upstream for v7.4:
pinctrl: airoha: limit GPIO interrupts to interrupt-capable pins
dt-bindings: pinctrl: Add EcoNet EN7528 pin controller
pinctrl: airoha: add support of en7528 SoC
The AN7563 driver from v7.3 comes along because the first of those
touches it, and a not yet upstream fix for the GPIO direction bits is
added on top. That one clears both bits of the two bit GPIO_CTRL field
instead of only the LSB, so a bootloader leaving the reserved value
behind no longer keeps the pin from driving.
Only GPIO0-GPIO15 are wired to the interrupt controller, and
gpiod_to_irq() now fails for the others rather than handing out an
interrupt that can never fire. Split the buttons accordingly: those
below GPIO16 become interrupt driven gpio-keys, the rest stay in a
gpio-keys-polled node.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25013
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The EN7528 pin controller support that follows needs the Airoha pinctrl
driver in its v7.3 shape: moved out of drivers/pinctrl/mediatek into its
own directory and split into shared code plus per-SoC drivers.
The airoha target already carries that whole chain for 6.18, so copy the
patches from there.
No functional change.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25013
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Port MediaTek commit 6a4c41c41410 ("fix timer inaccurate"), which
corrects the architected timer rate from 13 MHz to 12,986,200 Hz in the
DTS files for both MT7986A and MT7986B.
Upstream mt7986b.dtsi includes mt7986a.dtsi, so add the corrected rate
once to the common timer node. This makes the architected timer driver
override the 13 MHz value reported by firmware through CNTFRQ_EL0 for
both SoC variants.
The resulting 1062 ppm discrepancy exceeds the kernel's 500 ppm NTP
correction limit. This matches reports of sysntpd remaining saturated at
+500 ppm on the GL-MT6000.
Link: https://github.com/mediatek/mtk-openwrt-feeds/commit/6a4c41c41410cd5042ad10c39da6593ba036283c
Link: https://github.com/openwrt/openwrt/issues/24789
Signed-off-by: Andrea Pesaresi <andreapesaresi82@gmail.com>
The board names its six ports through ethernetN aliases for the bootloader
to patch an address into, and since the PPE conversion only the first two
arrive. On r35301-d47ce71a89, the last snapshot before it, every port came
up on an address of its own; on r35323-7ff96bf05c, the first one after,
lan1, lan2, 10g-1 and 10g-2 have none and inherit the conduit's, so four
ports and the bridge above them all answer to one MAC.
The addresses the bootloader hands out come from the MAC table at the start
of 0:art, one 6-byte slot per ethernetN alias. Describe those slots, so the
ports can read them whatever the bootloader does. ipq8071-ax3600.dtsi
describes its own ART table the same way.
The mapping is confirmed on a 301w: the table holds 24:5e:be:55:69:32
through :37 in slots 0 to 5 and nothing else, and the pre-conversion
snapshot brought up each port on the slot its alias names - lan4 on :32,
lan3 :33, lan2 :34, lan1 :35, 10g-1 :36, 10g-2 :37.
of_get_mac_address() consults the DT properties before the nvmem cell, so
a port the bootloader patched keeps the address it has.
Fixes: f50435627d ("qualcommax: ipq60xx/ipq807x: convert to PPE networking stack")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24528
Signed-off-by: Robert Marko <robimarko@gmail.com>
A fixed link carries no in-band negotiation, so the UNIPHY channel has to
be told to take its speed from the channel register instead of waiting
for a word that never arrives. The driver does that only on IPQ5018 and
leaves a TODO for the other two SoCs.
There is nothing to work out for them: the SSDK writes the same bit on
all three. Its IPQ5018 path, adpt_mp_uniphy_mode_ctrl_set(), writes
newaddedfromhere_ch0_force_speed_25m through
hppe_uniphy_channel0_input_output_4_set(), and its IPQ6018/IPQ8074 path,
__adpt_hppe_uniphy_sgmii_mode_set(), writes the same field through
hppe_uniphy_channel0_force_speed_mode_set(), a wrapper around that same
accessor - UNIPHY_CH_CTRL bit 3, at the same offset on every generation.
The vendor condition, PHY_F_FORCE, comes from the port's forced-speed and
forced-duplex DT properties, which is a fixed link: what phylink reports
as an outband neg_mode with no PHY expected.
Drop the SoC test, and clear the bit for a port that is not a fixed link
as the vendor does, so a channel cannot keep a force left from an earlier
mode. The same function also serves USXGMII and 10GBASE-R, where the XPCS
drives the channel and UNIPHY_CH_CTRL is not the register in play - the
SSDK writes the bit only from its SGMII mode sets - so neither write is
made in those modes.
A forced channel then reads its speed from the SPEED_MODE field next to
that bit, which nothing ever wrote - the SSDK has an accessor for it and
no caller. It kept its 1000 Mbps reset value while pcs_link_up() moved
only the RX and TX clock rates, so a fixed link at 10 or 100 Mbps drove
the channel at the wrong speed. Program the field from the speed
pcs_link_up() is handed, in the encoding the receive path already decodes
out of the status register, and only for a channel the same predicate
reports as forced: an in-band channel carries its speed in the negotiated
word and leaves the field unread. 2500BASE-X has no encoding of its own -
SGMII+ carries the rate in the mode - and keeps the 1000 value the vendor
leaves there.
Exercised on a Xiaomi AX3600 (IPQ8074, kernel 6.18), whose four ports
share UNIPHY0. Behind a QCA8075 the clear leaves FORCE_MODE at 0 and
SPEED_MODE at its 1000 reset value, and a port linked at 100 Mbps holds
that value while its UNIPHY port clock follows the link down to 25 MHz,
so pcs_link_up() runs for the lower speed and leaves the field to the
in-band word. Channels of the same instance declared as fixed links read
back FORCE_MODE set with SPEED_MODE following the declared speed - 0 at
10 Mbps, 1 at 100 and 2 at 1000 - and the channels still behind a PHY
unchanged. The eleven IPQ5018 boards with a fixed link on a UNIPHY all
declare 1000 Mbps, the value the field already holds, so the speed half
is a latent defect there rather than a visible one, and no IPQ6018 or
IPQ8074 board in the tree has a fixed link on a UNIPHY at all.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
phylink_get_inband_type() omits PHY_INTERFACE_MODE_PSGMII, so
phylink_pcs_neg_mode() returns early with PHYLINK_PCS_NEG_NONE for a
PSGMII port, and the in-band capabilities a PCS advertises are never
consulted: qca-uniphy answers pcs_inband_caps() with
LINK_INBAND_DISABLE | LINK_INBAND_ENABLE for every interface it drives,
PSGMII included.
Backport upstream commit 5ba017f9efef ("net: phylink: treat PSGMII as an
inband capable interface"), which classifies PSGMII as INBAND_CISCO_SGMII
beside SGMII and QSGMII and extends the generic clause 22 PCS helpers to
match, to both kernel copies the tree carries.
No board in the tree declares managed = "in-band-status" on a PSGMII
port, so every PSGMII port moves from PHYLINK_PCS_NEG_NONE to
PHYLINK_PCS_NEG_OUTBAND, PHY-managed and fixed links alike. A PCS
driver can distinguish the two with phylink_expects_phy() and force
its channel only on a fixed link.
The 6.12 copy adapts the phylink_mii_c22_pcs_decode_state() hunk, whose
SGMII case carries no neg_mode guard on that kernel.
Exercised on a Xiaomi AX3600 (IPQ8074, kernel 6.18), whose four ports are
PSGMII channels of one UNIPHY. With two of them declared as fixed links,
the channel force bit the qca-uniphy PCS drives reads 0 without this
patch and 1 with it, the channel speed field following the declared
speed, while the two channels still behind a PHY are untouched either
way. On the unmodified device tree nothing changes: every port links as
before and every channel register reads the value it held.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
A PCS taken from the phylink PCS list is attached to its phylink instance
in phylink_start(), after phylink_mac_initial_config() has already run
.pcs_config() on it, so that first call sees a NULL pcs->phylink. The
.mac_select_pcs() route has no such window: phylink_major_config() sets
pcs->phylink before it configures the PCS, which is what phylink did for
every PCS before the list existed.
DSA has no .mac_select_pcs, so every DSA port whose PCS comes from a
pcs-handle takes the list route. pcs-qca-uniphy reads the back-reference
in .pcs_config(), through phylink_expects_phy(), to tell a fixed link
from a PHY that simply does not negotiate in band, and a Zyxel NBG7815
panics on the wan port as netifd brings it up:
qca-ppe 3a000000.ppe wan: configuring for phy/2500base-x link mode
Unable to handle kernel access to user memory outside uaccess routines
at virtual address 0000000000000044
pc : phylink_expects_phy+0x0/0x38
lr : qca_uniphy_pcs_config_mode.isra.0+0x398/0x45c
Call trace:
phylink_expects_phy+0x0/0x38 (P)
qca_uniphy_pcs_config+0xec/0x13c
phylink_major_config+0x1e8/0x670
phylink_mac_initial_config+0xb8/0x14c
phylink_start+0x4c/0x280
dsa_port_enable_rt+0x48/0xb0
Its four psgmii ports come up first because psgmii has no in-band type at
all, which short-circuits the read, and its 10g port is managed in band.
Link the list where pl->pcs_state has just become PCS_STATE_STARTING, so
the guarantee holds on both routes. A .pcs_change() from a PCS that is
now linked earlier still resolves to nothing: phylink_run_resolve() does
nothing while phylink_disable_state holds PHYLINK_DISABLE_STOPPED, which
only the phylink_enable_and_run_resolve() below clears. The other two
phylink_mac_initial_config() callers are unaffected, both running with
the list already linked - phylink_resume() only takes that path when it
did not stop, and phylink_sfp_set_config() is gated on not being stopped.
The move rides in a patch of its own rather than an edit to the imported
737-02/770-02, so the imported series stays as it was taken. Both kernels
carry that series and both get the patch. No 6.12 target consumes the PCS
list today - the only in-tree filler lives under a files-6.18 directory
and every target that would use one is on 6.18 - so nothing there is
broken by the window; the two copies just have to stay the same patch.
Runtime tested on a Xiaomi AX3600 (IPQ8074, QCA8075 PSGMII, kernel 6.18):
the first .pcs_config() on every channel finds pcs->phylink set, at boot
and again after an admin down and up, which unlinks the list in
phylink_stop() and relinks it on the next start. The panic itself is not
reachable there, since psgmii has no in-band type and the resulting
PHYLINK_PCS_NEG_NONE short-circuits the read before it happens; that arm
runs on the NBG7815 in the report.
Fixes: 18cbd83a14 ("generic: 6.18: import updated standalone PCS handling")
Link: https://github.com/JuliusBairaktaris/openwrt-nss-edma/issues/23
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
Align all macro replacement values in qca_ppe.h with the header's dominant tab stop.
This is a whitespace-only cleanup.
Signed-off-by: Robert Marko <robimarko@gmail.com>
The STP APP_CTRL rule uses 0x93fc for its third word. CMD occupies
bits 16:15 of that word, so this selects DROP (1), not the intended
REDIRECT_TO_CPU (3). Incoming BPDUs never reach the bridge protocol
implementation even though ordinary traffic continues to work.
Correcting only CMD exposes another issue: the 0x7f ingress port mask
includes CPU port 0. CPU-originated BPDUs are then trapped back to the
CPU rather than transmitted to the selected external port. Exclude
the CPU and SoC-specific loopback ports, deriving the remaining mask
from the port count. Use named fields for the third word so the action
and port selection are explicit.
On an AX3600/IPQ8074 running 6.18.44, register readback confirmed the
original rule. A guarded runtime test of 0x193fc restored BPDU reception
but captured locally generated BPDUs on the CPU RX path. With 0x193f4,
those RX reflections disappeared and the adjacent switch received
bridge protocol traffic again. Reapplying that value automatically
after a reboot established RSTP with the upstream root. The patched
driver also builds against the matching aarch64 kernel SDK.
IPQ6018's generated mask was checked, but not tested on hardware.
Fixes: 142104bb90 ("qualcommax: add PPE driver")
Assisted-by: OpenAI Codex
Signed-off-by: Jan Leon <Jan.gaschler@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25063
Signed-off-by: Robert Marko <robimarko@gmail.com>
Netgear RBx850 are tri band, 2.4GHz and 2x 5GHz, 12 stream 802.11ax mesh
devices from the Orbi series. The RBR850 is a router with a 2.5GbE WAN and
4 1GbE LAN ports. The RBS850 is a satellite without WAN port and half the
flash. The hardware is otherwise identical. They were sold in kits as
RBK852-RBK855, with one router and 1-4 satellites.
The RBx850 are substantially similar to the RBx750 so this commit factors
out a common DTS, flash script and build definition.
Hardware:
* SoC: Qualcomm IPQ8074
* RAM: 1GiB 2x Samsung 4A4G165WE-BCRC
* Flash: 512MiB Winbond W29N04GZ or 256MiB Winbond W29N02GZ
* WLAN 2.4GHz: QCN5024 4x4:4 b/g/n/ax
* WLAN 5GHz Low Band: QCN5054 4x4:4 a/n/ac/ax 5180-5320MHz
* WLAN 5GHz High Band: QCN5054 4x4:4 a/n/ac/ax 5500-5700MHz
* Ethernet: 4x 1GbE LAN, 1x 2.5GbE WAN on RBR850
* Serial Config: 3.3V TTL 115200-8-N-1, internal populated header
* Serial Layout: Bottom <- RX, TX, GND, 3.3V (don't connect) -> Top
* LEDs: green/red power, white/red/green/blue status
* Buttons: 1x Reset, 1x WPS
MAC addresses:
LAN1: Label
LAN2: Label + 1
LAN3: Label + 2
LAN4: Label + 3
WAN: Label + 1
2.4GHz: Label + 2 (RBR) or 1 (RBS)
5GHz-Low: Label + 3 (RBR) or 2 (RBS)
5GHz-High: Label + 4 (RBR) or 3 (RBS)
Flashing Notes:
The stock firmware images are signed. Both the bootloader and the stock
web interface check the signature and will fail to boot/flash.
The bootloader automatically does NMRP when a gigabit LAN connection is
present. The stock and factory images contain a U-Boot script that is
executed when flashing using NMRP. This is used to alter and persist the
U-Boot env with a boot command that works with unsigned firmware.
Install OpenWrt:
* Get the nmrpflash utility [0] and OpenWrt factory image
* Find network interface to use: nmrpflash -L
* Start nmrpflash: nmrpflash -i interface -f openwrt-...-factory.img
* Connect one of the device LAN ports to the same network using gigabit
* Plug the device in and wait for the bootloader to flash
* Unplug and replug the device once the power LED on the back blinks amber
Revert to Stock:
The boot command needs to be reverted before flashing the stock firmware,
otherwise it will fail to boot and get stuck in recovery mode (red power
LED flashing).
* Still in OpenWrt run: fw_setenv bootcmd bootipq
* Restart the device
* Flash the stock firmware RBx850-Va.b.c.d.img using nmrpflash
[0]: https://github.com/jclehner/nmrpflash
Authored by Michael Lotz.
Piotr Szczepanik:
* Cherry-picked the RBx850 support commit from openwrt/openwrt#22159
and adapted it to current main.
* Reworked the DTS networking changes for the current qualcommax
ipq807x device-tree style.
* Verified the RBx750 DTS split preserves the existing RBx750-specific
layout while moving shared RBx750/RBx850 nodes into a common DTSI.
Signed-off-by: Michael Lotz <mmlr@mlotz.ch>
Signed-off-by: Piotr Szczepanik <piter75@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24906
Signed-off-by: Robert Marko <robimarko@gmail.com>
The GMAC on RTL9607C can handle ring sizes of up to 4096. Fix the comment
to now say 4096 is max instead of 256 and change the rx/tx ring sizes to 1024
and 2048 respectively to follow the vendor's defaults from their nic driver.
Also change the RX_BUF_SIZE to 1600 as the mentioned nic driver has the
SKB_BUF_SIZE set to 1600.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25042
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The last user of 8-bit regmap is GMAC_CMD register which can just as
well use 32-bit regmap whichout any issues. Change the register to
align with 4 byte and with that delete all of the 8-bit regmap stuff.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25042
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The current way of setting 1st rx ring and its flow control threshold values
are not exactly correct and doesn't follow register layout. In reality, the
register layout is much worse but still need to followed. This however, is
not the case for rx rings 2-6 as they have more sane register layouts.
Fix this up even if it is not the prettiest thing.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25042
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Enable ECDSA by default to:
- Support login with existing ECDSA keys.
- Ensure compatibility with legacy YubiKey devices (e.g., firmware 5.4)
and PIV-based SSH keys (RSA/ECDSA only).
- Maintain access until Ed25519 adoption is widespread.
Default 'y' for all builds except those with SMALL_FLASH.
This activates:
- DROPBEAR_ECC_256 (via DROPBEAR_ECDH || DROPBEAR_ECDSA), enabling
NIST-curve code for non-SMALL_FLASH builds.
- DROPBEAR_SK_ECDSA (default y), offering
sk-ecdsa-sha2-nistp256@openssh.com by default.
Note: Increases only binary size for non-SMALL_FLASH targets.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Link: https://github.com/openwrt/openwrt/pull/24685
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The packet steering script treats both threaded NAPI and the mt76 TX
worker as tasks belonging to the same wireless device. assign_dev_cpu()
then assigns all of these tasks to the same CPU.
This unnecessarily restricts the mt76 TX worker to the NAPI CPU even
though its affinity does not otherwise need to be constrained.
On MT7988A with MT7996 this caused the TX worker to share CPU3 with the
NAPI thread. Moving it to another CPU increased measured TX throughput
from 1.45 Gbit/s to 2.09 Gbit/s.
Stop matching the mt76 TX worker in the packet steering script. This
leaves its CPU affinity unrestricted and lets the scheduler place it
more appropriately.
Fixes: https://github.com/openwrt/openwrt/issues/24697
Signed-off-by: Gary Dotzler <geldot@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/25016
Signed-off-by: Robert Marko <robimarko@gmail.com>
mac80211 7.2 changes cfg80211 key and station operations to take a
wireless_dev instead of a net_device. It also updates station notification
helpers and the remain-on-channel callback.
Adapt the driver to the new API and bump the package release.
Signed-off-by: Alexander Zaguzin <st7105@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25020
Signed-off-by: Robert Marko <robimarko@gmail.com>
Patch 200 reverted the ath12k conversion from tasklets to BH workqueues.
It arrived with 88f4c32060 ("mac80211: update to version 6.14.11") in May
2025, when main still built kernel 6.6 on 26 targets; BH workqueues only
exist from 6.9, so the revert was doing real work then.
Main now builds 6.12 and 6.18. Both provide system_bh_wq and from_work(),
so there is nothing left for the revert to paper over.
It also leaves the driver inconsistent. backports 7.2 uses intr_wq in
ce.h, pci.c and ahb.c alike, and patch 200 converts only the first two
back to tasklets -- ahb.c was added to the driver after the conversion
landed and never got the same treatment. Building with ATH12K_AHB enabled
therefore fails.
Against pristine backports 7.2 the mac80211 patch series applies 151/151
with this patch removed, and no intr_tq reference survives in ath12k. An
ipq53xx build with ATH12K_AHB enabled links ahb.o cleanly, and the driver
probes an on-chip radio on real hardware.
Bump PKG_RELEASE so existing installs pick up the rebuilt module: it feeds
ABI_VERSION for the kmod packages.
Signed-off-by: Hideo Sumi <hideo.sumi@mugops.com>
Link: https://github.com/openwrt/openwrt/pull/24978
Signed-off-by: Robert Marko <robimarko@gmail.com>
The bridge drops a port's multicast entries on every leave, STP
transition and membership expiry, per port and without tracking which
entries this switch programmed. A delete therefore arrives both for
entries that were never added - the add path runs only for ports in an
offloaded bridge - and for entries an earlier delete already emptied.
ppe_fdb_lookup() reports those as -ENOENT and the driver returned it.
Nothing acts on that return: the object is deleted through switchdev's
deferred queue, where switchdev_port_obj_del_deferred() turns any error
other than -EOPNOTSUPP into a log line and discards it. The error only
produced kernel noise for a state that already matched the request. A
port that is not in the entry's portmap is the same case one step
further in.
Return success for both. The path that drops an entry once its last
member outside the CPU port leaves is unchanged.
Measured on an ipq8074 board with multicast snooping enabled, one group
joined by lan1, lan2 and lan3, and the three ports then removed from
the bridge in turn:
qca-ppe 3a000000.ppe lan3: Failed to del Port Multicast Database
entry (object id=2) with error: -ENOENT (-2).
twice before this change and not at all after it, the ports returning
to the bridge either way.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24968
Signed-off-by: Robert Marko <robimarko@gmail.com>
kbuild dropped EXTRA_CFLAGS in 6.15 (e966ad0edd00, "kbuild: remove
EXTRA_*FLAGS support"), so on 6.18 the define never reaches the
compiler and the module logs "nat46: module (version unknown) loaded".
CFLAGS_MODULE is read by both 6.12 and 6.18.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25057
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, the LAN1 LED usually doesn't work on Nokia XG-040G-MD and
Nokia XG-040G-MF devices: it lights up right after boot but goes dark
again as soon as the link renegotiates. Both boards wire LAN1 to a
discrete Airoha EN8811H PHY, whose LED GPIO pins are only ever
configured as outputs once, in en8811h_probe(); every later call to
en8811h_config_init() restarts the PHY's MD32 MCU, which resets that
GPIO configuration back to inputs.
Backport the fix that moves the GPIO-as-output configuration into
en8811h_config_init() so it is reapplied on every MCU restart. This is
a fix to the generic Linux PHY driver (drivers/net/phy/air_en8811h.c),
not something specific to the airoha target: other targets ship the
same PHY via kmod-phy-airoha-en8811h (e.g. mediatek/filogic boards),
so it belongs in target/linux/generic/backport-6.18/ rather than under
target/linux/airoha/.
Merged upstream into net.git by Paolo Abeni as commit 03b4702fc5e3
("net: phy: air_en8811h: move LED GPIO configuration to config_init"),
expected in v7.3. The patch is functionally identical to that commit,
refreshed into OpenWrt's quilt form.
Suggested-by: Mikhail Zhilkin <csharper2005@gmail.com>
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24853
Signed-off-by: Robert Marko <robimarko@gmail.com>
NET_AIROHA_NPU is built-in and probes before rootfs is mounted, so
request_firmware() correctly fails with -ENOENT. The driver maps that
to -EPROBE_DEFER and succeeds once /lib/firmware is available.
With CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y (inherited from generic),
a missing firmware instead blocks ~60s on the sysfs userspace helper
and returns -ETIMEDOUT. That is not mapped to -EPROBE_DEFER, so NPU
probe fails permanently:
Direct firmware load for airoha/en7581_MT7996_npu_rv32.bin failed with error -2
Falling back to sysfs fallback for: airoha/en7581_MT7996_npu_rv32.bin
error -ETIMEDOUT: failed to run npu firmware
probe with driver airoha-npu failed with error -110
This shows up on official / firmware-selector images because
CONFIG_ALL_KMODS=y builds kmod-leds-lp55xx-common, which implies
FW_LOADER_USER_HELPER and then FALLBACK from generic takes effect.
Match bcm53xx/gemini/layerscape: keep FW_LOADER_USER_HELPER (from
generic) and unset only FALLBACK on an7581/an7583. Unsetting both is
not refresh-safe — FALLBACK depends on USER_HELPER, so
make target/linux/refresh drops the FALLBACK line when USER_HELPER is
off, and ALL_KMODS builds then reintroduce the -ETIMEDOUT failure.
With FALLBACK disabled, early firmware misses keep returning -ENOENT
and deferred probe can load the NPU firmware after rootfs.
Fixes: https://github.com/openwrt/openwrt/issues/22709
Supersedes: https://github.com/openwrt/openwrt/pull/22697
Signed-off-by: Daniel Pawlik <pawlik.dan@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24571
Signed-off-by: Robert Marko <robimarko@gmail.com>
On IPQ8074 a firmware assert reboots the SoC.
ath11k_core_reconfigure_on_crash() frees the data path and clears the
ring list while the DP NAPI is still polling, so the NAPI services a ring
whose address pointer has just been cleared:
Unable to handle kernel read from unreadable memory at virtual address 0
pc : ath11k_hal_srng_access_begin+0xc/0x60 [ath11k]
Call trace:
ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P)
ath11k_dp_rx_process_mon_rings+0xa0/0x5d4 [ath11k]
ath11k_dp_service_srng+0x1f4/0x348 [ath11k]
ath11k_ahb_ext_grp_napi_poll+0x34/0xd4 [ath11k_ahb]
951 disables the interrupts on the crash path again. 950 is its
prerequisite: it wires up the CE interrupt ops that
ath11k_ahb_hif_ops_ipq8074 never set, which leaves the CE half of the
quiesce a no-op on AHB. Both are in ath-next as commit a7ab5c835e42
("wifi: ath11k: implement CE interrupt enable/disable for AHB") and
commit f7a74e131d3f ("wifi: ath11k: disable interrupts during firmware
crash recovery"), and are carried here verbatim.
Tested on a Xiaomi AX3600 (IPQ8074 hw2.0) with the debugfs
simulate_fw_crash assert trigger: one assert panics and reboots the SoC
before, five asserts recover after.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24578
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL8221B unfortunately suffers from a issue where reading registers from
MMD 30 can break the PHY. Once it is in the broken state, recovery is
only possible by hardware reset.
Add a hack which prevents the kernel from reading MMD 30 while probing
for PHYs when a RTL8221B is detected, based on the ID from MMD 1.
Fixes: https://github.com/openwrt/openwrt/issues/22140
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/25017
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The notifier patch attached phydev->psec under rtnl_lock() inside
phy_device_register(). Drivers that register their MDIO bus from
ndo_init() (like the lantiq etop) already hold rtnl at that point, so the
attach tried to take rtnl a second time and deadlocked on probe.
Aleksander hit this on lantiq arx100.
Rework 896-03 to use a dedicated mutex instead of rtnl for the psec
attach, the notifier walks and the ethtool PSE paths, so there is no rtnl
recursion any more.
The mutex lives in pse_core.c rather than in phylib: net/ethtool is always
built into vmlinux while PHYLIB is tristate, so net/ethtool/pse-pd.c must
not call a phylib export or CONFIG_PHYLIB=m fails to link. PSE_CONTROLLER
is bool, so pse_core is either in vmlinux or absent and every config can
reach pse_phy_lock()/pse_phy_unlock(); !PSE_CONTROLLER gets no-op stubs in
pse.h.
phy_device_register_locked() is gone with it. It only existed because the
attach took rtnl, and was identical to phy_device_register() apart from an
ASSERT_RTNL(), so sfp.c calls phy_device_register() again and
include/linux/phy.h stays untouched.
Also refresh 897-01 and 897-02, whose hunks shift.
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/24945
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
*_pie_verify_template() gates the SMAC / DMAC template requirement on
ether_addr_to_u64(pr->smac) / pr->dmac, i.e. on the match value, while
every neighbouring field (sip_m, dip_m, ethertype_m, itag_m, sport_m,
dport_m) is gated on its mask. A rule matching the all-zero MAC -
"flower dst_mac 00:00:00:00:00:00", full mask, zero value - then passes
verification against a template that has no DMAC field and is programmed
to match every frame instead of just that address.
Gate on smac_m / dmac_m like the other fields. Pre-existing in all four
*_pie_verify_template() implementations; only rtl930x was exercised
(tc cls_flower offload), the other three are changed for consistency.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25050
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtl83xx_delete_flower() called pie_rule_rm() - which takes pie_mutex -
while still holding rcu_read_lock(), i.e. it could sleep inside an RCU
read-side critical section.
Remove the flow from the hashtable and drop the RCU lock first, then tear
down the hardware rule outside the critical section. Propagate the
rhashtable_remove_fast() error and return -ENOENT (not -EINVAL) when no
flow matches the cookie.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25050
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtl839x_pie_rule_read() selects table type 2 through RTL8380_TBL_0,
the RTL838x table access block, while its own comment names the IACL
table and the matching rtl839x_pie_rule_write() reaches it through
RTL8390_TBL_0.
The two blocks differ in more than their address. RTL8380_TBL_0 drives
the command register at 0x6914, with the execute bit at 15 and the
inverted read/write polarity rtl_table_exec() applies to RTL838x;
RTL8390_TBL_0 uses 0x1190, execute at 16 and normal polarity. On an
RTL839x the reader therefore drives the RTL838x table register at
0x6914 and takes its seventeen words from 0x6918 instead of 0x1194.
rtl_table_get() also locks the descriptor it is handed, so the reader
holds a different mutex from the one the writer holds and the two do
not serialise against each other.
Nothing reaches this today: .pie_rule_read is populated for RTL838x
and RTL839x but is never invoked through priv->r, so the defect is
latent and no failure has been observed. It is fixed because the
reader and the writer have to agree before either becomes reachable.
Compile-tested on realtek/rtl839x. Not run on hardware, no RTL839x
board here; the change selects the table the writer already selects.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25051
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
parse_encryption returns leaves config.auth_type unset in case
encryption is unset. However, the owe_transition_iface config option for
the unencrypted network is currently only set in case encryption is
explicitly set to 'none'.
These two should be identical in their behavior. Set the encryption to
"none" in case it is unset and do not return. This aligns the behavior
of unset encryption with encryption explicitly set to 'none'.
Signed-off-by: David Bauer <mail@david-bauer.net>
*_pie_verify_template() rejected a template that lacked the SIP, DIP,
SMAC or DMAC field a rule needs, but silently accepted one missing the
L4 source/destination port or inner-VLAN fields. When such a template
was picked the corresponding match was simply dropped: a
"flower ip_proto udp dst_port 5353" offload installed against an L2-only
template matched every UDP frame instead of just mDNS.
The same gap exists identically in all four PIE-based SoCs (rtl838x,
rtl839x, rtl930x, rtl931x): each verify_template() stops at the SMAC/DMAC
check and never looks at the L4 port or VLAN fields.
Reject a template that does not carry the port/VLAN field the rule masks,
so the block search falls through to one that does.
The failure was observed on an RTL9302C (Zyxel XGS1210-12, rtl930x): a
dst_port 5353 drop rule also counted UDP sent to other ports. rtl838x/
839x/931x share the same verify_template() structure and template
layout, so the fix is applied there too, though only rtl930x hardware
was available to reproduce and verify it.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The FLOW_ACTION_TRAP handler filled in fwd_data and fwd_act but left
fwd_sel clear, so the PIE never actually selected the forwarding action
and trapped packets were not redirected to the CPU port.
Set fwd_sel like the other forwarding actions do.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The EtherType value in struct pie_rule is a u16, but its mask field was
only u8, so it cannot express a full 16-bit match. Widen the mask to
match the value it applies to.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtl839x_pie_rule_add(), rtl930x_pie_rule_add() and rtl931x_pie_rule_add()
split the PIE blocks into an ingress and an egress half and only scan the
half matching the rule's phase, but the "nothing found" check still
compared against the full block count. For a rule that exhausted its half
the loop then fell through with a stale block/index instead of returning
-EOPNOTSUPP.
Compare against max_block so an exhausted phase range fails cleanly.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
On RTL930x two packet counters share a single LOG table entry, so the
counter ID is halved when addressing the table. rtl930x_packet_cntr_clear()
zeroed one of the two registers and then wrote the whole entry back
without first reading its current contents, wiping the adjacent counter
with whatever stale data happened to be in the table register cache.
Read the entry before modifying one half so the adjacent counter is kept
intact.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtldsa_93xx_lag_set_group2ports() gets an already locked table handle
from priv->r->lag_table() and releases it only on the success path, so
both error returns leave the mutex held for good.
The lock covers a whole table access register rather than one of its
tables, so the damage is wider than LAG: on RTL930x that register also
carries VLAN, the ingress ACL, spanning tree state, the packet counters
and port isolation, and every later access to any of them blocks. On
RTL931x the LAG table shares its register with port isolation.
Only the -ENOSPC path can be reached today, when a bond has more than
eight member ports; nothing bounds the member count before it.
Callers cannot reach the -EOPNOTSUPP path because
rtldsa_port_lag_join() already rejects any hash type other than
NETDEV_LAG_HASH_L2 and L23 in rtldsa_83xx_lag_can_offload(), and the
remaining callers pass a NULL info, but the missing release is a trap
for whoever changes that guard.
Not reproduced on hardware: the board here has eight ports, one too few
to trigger the reachable path, and no RTL931x is available.
Compile-tested on realtek/rtl930x and realtek/rtl838x.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25036
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Uboot-Envtools is installed by default on the mpc85xx target.
Add the proper configuration for the Sophos RED 15w, so the fw_*env
commands will actually work.
Fix alphabetic sorting in the case statement while we're at it.
Signed-off-by: Shine- GH <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/24939
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Remove userspace handling for the wifi MAC as nvmem is available to
handle this.
Add label-mac-device support for similar reasons. The ethaddr MAC shows
up on the label on the device.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24699
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
rtpcs_931x_sds_link_sts_get() is marked __always_unused and has no
callers. The active PCS paths now contain the status handling they
require, so remove the dormant SDK-derived diagnostic helper.
Link: https://github.com/openwrt/openwrt/pull/24986
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
pcs_get_state always read the MAC-side link/speed mirror registers,
regardless of SerDes mode. For Clause 37 modes, that mirror can go stale:
a speed renegotiated purely at the SGMII/PCS level is visible in the SerDes
LPA register immediately, but the MAC-side mirror only refreshes when the
MAC force-enable selector is pulsed.
Read the SerDes Clause 22/37 BMSR and LPA registers directly for SGMII,
1000BASE-X and 2500BASE-X, and decode them with the standard phylink helper.
Read BMSR twice because its link status is latched low. Keep all other
SerDes modes on the existing MAC-side mirror path.
When SGMII operates without in-band negotiation, preserve the speed,
duplex and pause settings supplied by phylink; the PCS decoder only updates
link state in that mode.
This fixes PCS state reporting for the SGMII speed-change bug reported on
RTL930x SFP ports. Refreshing the MAC datapath with a force-enable pulse will
be handled separately later.
Link: https://github.com/openwrt/openwrt/issues/23055
Link: https://github.com/openwrt/openwrt/pull/24986
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Both RTL93xx variants use the same link status bit for 10GR links.
Rename the RTL931x helper to rtl93xx so it can be shared by both
variants.
The link status is latched low, so discard the first read and return
the current state from the second. Use the helper in the RTL930x
state-machine initialization instead of open-coding the two reads.
Link: https://github.com/openwrt/openwrt/pull/24986
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Robert Marko
David Yang
Andy Chiang
Ahmed Naseef
Andrea Pesaresi
Julius Bairaktaris
Jan Leon
Piotr Szczepanik
Michael Lotz
Cui Shuang
Qingfang Deng
Rustam Adilov
Florian Eckert
Gary Dotzler
Alexander Zaguzin
Tianling Shen
Hideo Sumi
Hannu Nyman
Vitaliy Sochnev
Daniel Pawlik
Jan Hoffmann
Carlo Szelinsky
Mark Abe
Gennaro Cimmino
David Bauer
Shiji Yang
Shine- GH
Rosen Penev
Jonas Jelonek