Manually adjusted symbols:
- SOC_SAMA7D65: SAMA7D65 family
- PAGE_BLOCK_MAX_ORDER: Page Block Order Upper Limit
- SPI_POLARFIRE_SOC: Microchip FPGA SPI controllers
All other kernel config symbols are automatically refreshed by
`make kernel_oldconfig`.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/25436
Signed-off-by: Robert Marko <robimarko@gmail.com>
Two symbols needed input, the respective default was picked:
- CONFIG_PAGE_BLOCK_MAX_ORDER, default 10
- CONFIG_FRAME_WARN, but was dropped by kernel oldconfig
The other symbol changes are automatic.
Signed-off-by: Lars Gierth <larsg@systemli.org>
Link: https://github.com/openwrt/openwrt/pull/25421
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL839x route dump reads a ROUTING row back with
otto_l3_839x_nexthop_read(), which fills a whole route to hand over a
gateway MAC and a switch MAC entry. Read DMAC entries back the way they
are written instead: get_dmac() fills the struct otto_l3_dmac that
set_dmac() takes. RTL839x decodes the gateway MAC and SW_MAC_IDX from
the row; RTL930x reads the MAC from its egress MAC table and leaves
smac_id at 0, since its egress interfaces name the source MAC. A read
that fails returns its error, and the dump prints "-" for it.
Only the RTL839x dump uses it; nothing else changes. On an HPE 1920-48G
(RTL8393) it reads back the gateway MAC with MAC_ID 1 for a route out of
a device with a MAC of its own, and 0 for one out of the switch MAC.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25852
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Common code reaches the source MACs of the two families in two ways:
RTL930x callers add L3_EGRESS_DMACS to an index of its egress MAC
table, which holds destination and source MACs alike, while RTL839x
writes its switch MAC entries through set_switch_mac(). Give both the
same pair, get_smac() and set_smac(), on the index of the source MAC
entry: RTL839x reads and writes ROUTING_SA_CTRL, RTL930x adds
L3_EGRESS_DMACS itself, so the layout of its table stays in the RTL930x
code.
The accessors report a failed table access, and the callers act on it
where they can. An egress interface whose source MAC cannot be written
is not taken, and its route is not offloaded; nor is a switch MAC entry
that cannot be written, and its route keeps to the CPU. The allocator
skips a source MAC it cannot read: it is neither free nor a match. An
interface that cannot take its device's new MAC keeps the old one, as
when none is free. A source MAC that cannot be cleared when its last
route goes, or at RTL930x setup, is logged; a failed setup would fail
the whole switch probe. The RTL930x next hop dump prints "-" for one it
cannot read. Before, all of these were ignored. The egress interface
allocator returns -ENOSPC rather than -1 when none is free, as
otto_l3_dmac_get() and otto_l3_switch_mac_get() do.
RTL839x writes registers, which cannot fail, so it behaves as before.
Tested on an HPE 1920-48G (RTL8393): a VLAN device with a MAC of its
own takes switch MAC entry 1, frames to it are routed in hardware, and
the entry is freed when the routes holding it go. RTL930x
compile-tested only.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25852
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The common L3 code tells the RTL839x source MAC model apart by whether
the family sets set_switch_mac: there a route takes the source MAC
entry of the device it goes out of, its DMAC entry names that entry,
and the entries are also the MACs whose frames are routed. Once both
families reach their source MACs through the same operations, that
test no longer tells them apart.
Name the model with smac_per_route, set for RTL839x, and test that
wherever the code chose it by set_switch_mac. No functional change:
RTL839x sets both, RTL838x, RTL930x and RTL931x neither.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25852
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
VLAN support is broken on MT7530/MT7531 switches (seen on the ASUS
ZenWiFi BT8): after a VLAN-aware bridge is destroyed, VLAN-unaware
bridges lose connectivity, and untagged PVID traffic does not reach
the bridge VLAN upper interface (br-lan.<vid>).
Backport two fixes from Linux v7.1:
- 2c4c76cacc9d ("net: dsa: mt7530: fix CPU port VLAN not being reset
to unaware")
- 4cb3cd670b2a ("net: dsa: mt7530: untag VLAN-aware bridge PVID")
Both patches apply cleanly to 6.18 and were refreshed with
make target/linux/refresh.
Fixes: https://github.com/openwrt/openwrt/issues/18576
Signed-off-by: Marc Strämke <marcstraemke@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25247
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A flower rule whose only action is a byte rate police is programmed as
the rate limiter of the port without a look at what the rule matches. A
rule that polices broadcast frames to 10 Mbit/s limits all traffic of
the port to 10 Mbit/s.
Deleting has the matching defect: the delete callback also arrives for
rules that never made it into the hardware, and any of them that is not
a PIE rule switches the limiter of the port off, while the rule that
set the limiter up is still reported as offloaded.
Program the limiter only for a rule that reaches every frame of the
port: in chain 0, for all protocols and without match. Remember which
rule that was and remove the limiter only when this rule goes. Any
other police rule is no longer offloaded.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Quinn O'Shea <qoshea@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25845
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The wdr4300.dtsi USB port feeds a 4-port GL850G hub, so the LED trigger
sources are its four downstream ports. Override usb0 to drop the generic
trigger node and declare the hub with its device ID, mirroring the NEC
aterm boards.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25340
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Pi-WiFi4 USB port feeds a 4-port GL850G hub, so the LED trigger
sources are its four downstream ports. Override usb0 to drop the generic
trigger node and declare the hub with its device ID, mirroring the NEC
aterm boards.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25340
Signed-off-by: Robert Marko <robimarko@gmail.com>
The &usb override re-declares hub_port/@address-cells/#size-cells with
values identical to the ones inherited from ar934x.dtsi, so it has no
effect. Drop it and leave only the status change.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25340
Signed-off-by: Robert Marko <robimarko@gmail.com>
Dynamic SGMII PHY links may remain software-forced, which prevents PCS
state changes from generating MAC link interrupts. Enable phylink PCS
polling for in-band SGMII so links recover after the PCS settles
following a mode change.
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL931x controls forced link, speed, duplex, and flow control with
separate enable bits. Describe the register layout and provide a MAC
link-state source selector so the common RTL93xx callbacks can manage
its force-mode transitions.
This supports fixed links, CPU ports, and dynamic SFP PHYs while
leaving statically described PHY links and direct PCS links
hardware-controlled. Dynamic SGMII and out-of-band PHYs remain forced,
while dynamic USXGMII PHYs return to PCS-controlled state after the
force pulse.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Use separate RTL83xx and RTL93xx link-down callbacks so their
family-specific force-mode handling can evolve independently.
The RTL83xx callback retains the legacy force-mode clearing behavior.
The RTL93xx callback preserves force mode for forced RTL930x links and
keeps PCS source selection with the corresponding link-down handling.
This also prepares the common RTL93xx path for RTL931x support.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Move the family-specific MAC force mode register layout into the switch
configuration. This removes family checks from the RTL83xx link-up path
and converts RTL930x handling to the same field descriptions.
Describe link-state and flow-control force enables separately along with
the fields used to construct resolved MAC state. This allows phylink's
resolved pause settings to remain forced when link state is controlled by
hardware. Add the initial RTL931x link-force description in preparation
for later RTL931x support.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL930x SFP ports may use either a directly attached SerDes module
or a module containing a PHY discovered after switch setup. Static
PHY polling cannot provide link state for the latter, while forcing
every port would override hardware state for PCS and statically
polled PHY links.
Program the MAC link-state source for non-static links. Dynamic SGMII
and out-of-band PHYs select their PHY state source and remain forced.
Dynamic USXGMII PHYs pulse force with the resolved parameters before
returning to PCS-controlled state. Fixed links and CPU ports also
remain forced.
Keep flow-control forcing independent from link-state forcing so
phylink's resolved pause settings remain active when link state returns
to hardware control.
Preserve force mode while a forced link is down so the MAC reports
the down state instead of reverting to its hardware source.
Tested on RTL930x hardware.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Convert switch register accesses in the phylink MAC configuration and
link callbacks to the shared regmap. Use regmap_update_bits() for masked
updates and regmap_read()/regmap_write() when assembling full force-mode
values.
The callbacks are void, so leave regmap return values unchecked to match
the existing callback behavior.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The switch register range is exposed by the device tree node as a syscon.
Obtain its regmap while probing and retain it in the private data so
register accesses can be converted to the regmap API. Return the
underlying error if the regmap cannot be obtained.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
fe_poll() enables the RX and TX interrupts after napi_complete_done()
without looking at its return value. napi_complete_done() returns false
when the interrupts have to stay masked, for example during busy
polling, or when IRQ deferral (napi_defer_hard_irqs together with
gro_flush_timeout) has armed a timer to poll again.
Only enable the interrupts when it returns true, as
Documentation/networking/napi.rst asks. The mainline mtk_eth_soc
driver does the same in mtk_napi_rx() and mtk_napi_tx(). The value
that fe_poll() returns does not change.
Fixes: https://github.com/openwrt/openwrt/issues/25742
Signed-off-by: Hsiu-Chi Tsai <hctsai@linux.com>
Link: https://github.com/openwrt/openwrt/pull/25744
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL839x offloads IPv4 routes only: IPv6 FIB, policy rule and neighbour
events are dropped where the L3 tables are not used (#25768 item 1).
Now that an L3 rule can match an IPv6 destination, take them: an IPv6
route gets a PIE rule matching its prefix and FRAME_TYPE IPv6, which
forwards to its gateway's L2 entry or traps, as an IPv4 one does.
IPv6 rules fill the L3 range from the last rule down and IPv4 ones from
rule 1 up, the longest prefix on the lowest rule in each, as on
RTL930x; FRAME_TYPE keeps the two apart, so either family can use the
whole range. An RTL839x rule holds a whole IPv6 destination and can
sit anywhere, where an RTL930x entry takes three rows in fixed places,
so the row helpers tell the two apart by use_l3_tables.
As on IPv4, an IPv6 route through a gateway takes the switch MAC
entry of the device it goes out of, and an address of the switch or an
on-link prefix that of its device: the trap rules match frames to the
switch's MACs, and a device with a MAC of its own and no IPv4 may have
no other route to take one. After a device's MAC change its IPv6
routes through a gateway are resolved again, through ndisc. A routed
IPv6 packet whose hop limit runs out goes to the CPU, which answers
it: IP6_HL_EXCEED, bits 9:8 of ROUTING_EXCPT_CTRL, set to 2, trap
(Realtek GPL SDK, rtk_cypress_regField_list.c for the field,
dal_cypress_trap.c for 0 drop, 1 forward, 2 trap). debugfs prints IPv6
rules.
Measured on an HPE 1920-48G (RTL8393), main 404823678f with this
series, 8 echo requests from VLAN 7 per case, forwarding off,
2001:db8:99::/48 via a gateway in VLAN 3 behind another port:
- blocks 0-3 select templates 1 and 3; the switch's IPv6 addresses,
on-link prefixes and ULA /48 trap from rule 511 down
- routed in hardware: 8/8 at the gateway, hop limit 63, source the
switch MAC, none at the CPU, the rule's counter +8
- with 2001:db8:99:5::/64 via a second gateway, added before or after:
:5:: to the second and :6:: to the first, 8/8 each, none at the CPU
- hop limit 1, 4 requests, IPv6 forwarding on: 4/4 to the CPU, 4 Time
Exceeded back. With bits 9:8 set to 1 instead the 4 reached the
gateway with hop limit 0, with 0 they reached nothing.
- gateway down: neighbour failed, the route trapped; back: forwarding
in hardware again
- an IPv4 route installed alongside: 8/8 each in hardware
- VLAN 7's device IPv6-only with a MAC of its own: that MAC took a
switch MAC entry and the 8 sent to it were routed in hardware, none
at the CPU; before addresses and on-link prefixes took one, it got
none and all 8 went to the CPU
- 2001:db8:99:6::/64 via the first gateway, then 140 more /64s and
the /48 via the second: the first /64 went down to rule 369, in
block 2, and took 8/8 there; :8:: went to the second through the
/48 on rule 511; with the 140 gone the /64 was back on rule 509,
8/8
- IPv4, 10.99.0.0/16 via one gateway and 10.99.5.0/24 via another,
added in either order: 10.99.5 to the /24's, 10.99.6 to the /16's,
8/8 each, none at the CPU
- IPv4, 10.99.0.0/16 via one gateway and 10.0.0.0/8 via another,
then 390 /32s via the other: the /16 went up to rule 399, in block 3,
and took 8/8 there, none at the CPU; with the 390 gone it was back
on rule 9
RTL930x: no change. Its IPv6 path took these events already, its row
helpers return what they did, and the rest depends on set_switch_mac,
on the RTL839x setup, writer or debugfs dump. RTL838x and RTL931x have
no setup, so their FIB and neighbour events are still ignored.
Compile-tested on rtl930x, with IPv6 and without.
Not tested: an IPv6 route out of a device with a MAC of its own, a MAC
change under IPv6 routes, an IPv6 policy rule over offloaded routes,
IPv6 rules in blocks 0 and 1, IPv4 and IPv6 rules meeting in a full
range, bridged IPv6 frames whose destination falls in an offloaded
prefix.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25838
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Since b98061ac6e ("realtek: pie: rtl839x: keep the first 512 rules
for L3") blocks 0-3 hold only L3 rules. Blocks 0-2 select templates 0
and 1, block 3 templates 2 and 3, and an L3 rule takes the first
template of its block that has the IPv4 destination (DIP0): template 1,
or template 2 in block 3. Of the fixed templates only template 3 holds
a whole IPv6 destination (DIP0 to DIP7), so an IPv6 rule could only go
to block 3.
Select templates 1 and 3 in blocks 0-3, and let an L3 rule that
matches an IPv6 destination take the template with DIP2, so that IPv4
and IPv6 rules can each use the whole L3 range (#25768). IPv4 rules
now match on template 1 in all four blocks, which holds the IPv4
destination as template 2 did in block 3. Blocks 4 and up keep their
templates.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25838
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtl839x_write_pie_templated() writes an IPv6 destination 16 bits per
template field, DIP0 the lowest and DIP7 the highest. The reader builds
it at DIP2 from whole register words instead, as the RTL838x reader
does, and skips DIP3 to DIP7, so a rule matching an IPv6 destination
reads back with the wrong address and mask. Read each field back into
the 16 bits it was written from; DIP0 and DIP1 fill the IPv6 address as
well as the IPv4 one.
No RTL839x rule matches an IPv6 destination yet; the following patches
add some and dump them through debugfs. On an HPE 1920-48G (RTL8393)
with them the dump showed the switch's IPv6 addresses and prefixes as
configured, e.g. fd00:90:3::1/128 and fd00:90:3::/64.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25838
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The switchdev VLAN object carries no protocol, so a VLAN added on a
bridge with vlan_protocol 802.1ad is programmed as an 802.1Q VLAN
without an error. The switch then matches it against the 802.1Q tag of
a frame, which such a bridge does not treat as its VLAN tag, while the
bridge believes the VLAN is offloaded.
Ask the bridge for its protocol and refuse anything but 802.1Q with an
error and an extack message. -EOPNOTSUPP would not do: the bridge takes
it as "keep this VLAN in software" and carries on silently. A host VLAN
arrives on the CPU port, which is in no bridge, so take the bridge from
the VLAN object there.
A port can then only join an 802.1ad bridge that has no default PVID
and no host VLAN, as the bridge adds those VLANs while the port joins.
Changing the protocol of a bridge that already holds ports is not seen
by the driver, as DSA does not forward that attribute.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Quinn O'Shea <qoshea@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25835
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
qca8k supports dual CPU just fine today.
port@6 was copy/paste from somewhere, so fix it up for all boards.
Since the raw interface is now part of the switch, remove it from the
bridge.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25466
Signed-off-by: Robert Marko <robimarko@gmail.com>
On RTL839x every routed frame leaves with the switch's own MAC,
whatever device the route goes out of, and frames to a device with a
MAC of its own are not routed: every ROUTING_SA_CTRL entry the driver
writes (0 to 14) holds the switch's MAC, and every ROUTING row names
entry 0 (#25768, items 3 and 4).
The 16 entries are the source MACs a ROUTING row names (SW_MAC_IDX,
Realtek GPL SDK, dal_cypress_l3_routeEntry_set()) and, as measured,
also the MACs whose frames the switch routes. Entry 0 stays the
switch's MAC (dal_cypress_l3_init()). Any other MAC that a route goes
out of a device with takes an entry, per MAC and held by the routes
through it, the on-link prefix included, so a device routes on its MAC
while it has an address, if an entry was free when it got it. A
ROUTING row is now keyed on the gateway's MAC and that entry. Unused
entries hold FF:FF:FF:FF:FF:FE, as the SDK leaves them.
What the hardware cannot do traps. A route through a gateway that
finds no entry free traps, and asks again on the gateway's next
neighbour update. Two devices with different MACs on one VLAN reach a
gateway through one L2 entry, which can name only one of their rows:
the routes already forwarding keep it. A device that takes a new MAC
has its entry rewritten when only its routes hold it and no other
entry has the new MAC; otherwise its routes move to an entry for the
new MAC, those through a gateway trapping until a resolve gives them
their new row, and the old entry, still routed, is given up only with
the rows that name it.
Measured on an HPE 1920-48G (RTL8393), on main f29dfe25ba with the
previous patch and bench debugfs files, before the rebase onto
e5ec5e199f; 8 echo requests per case, forwarding off, switch.3 and
switch.7 with MACs of their own (M3, M7), gateway G in VLAN 3 and, with
the same MAC, in VLAN 7, sending now and then as a live gateway does:
- from VLAN 7 to M7, route out of switch.3: 8/8 at G, TTL 63, source
M3 (on the #25808 image: 0/8, all to the CPU)
- routes via G out of switch.3 and switch.7: two ROUTING rows, 8/8
with M3 and 8/8 with M7
- switch.3 down: its entry freed, the switch.7 route still 8/8 with
M7; up again: M3 back, 8/8
- switch.7 to a new MAC: its entry rewritten in place, 8/8 with the
new MAC, the switch.3 route unchanged
- switch.7 to M3, which switch.3's entry holds: its routes moved to
that entry, its old one freed, both routes 8/8 with M3
- with one entry held, 16 more VLAN devices with MACs of their own:
the entries ran out after 14, and a gateway route out of a device
without one trapped; once the others were gone it took an entry on
its next neighbour update (debugfs and register reads, no traffic;
G was never on those VLANs, so before e5ec5e199f its routes there
got an invented L2 entry, and on main they trap for want of one:
only the switch MAC entries were checked)
- rerun from #25805 and #25808: two prefixes in both orders, one
gateway for two routes, neighbour loss: same results
Other RTL839x boards: routes keep entry 0, as before, while every
device they go out of has the MAC eth0 had at probe. A device with
another MAC now takes an entry, and frames to it are routed by the
switch instead of the CPU.
RTL930x sets no set_switch_mac: its routes take no entry, and its
netdev notifier path is unchanged. Compile-tested on rtl930x. RTL838x
and RTL931x have no setup, so their FIB and neighbour events are ignored
and none of this runs there.
Not tested: two devices with different MACs on one VLAN, a move to a
new entry, a device going back to the switch's MAC, a failed ROUTING
row write.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25822
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The DMAC entries are written through set_egress_mac() and keyed on the
gateway's MAC alone. That is what an RTL930x L3_EGR_INTF_MAC entry
holds, but an RTL839x ROUTING row also names the switch MAC entry a
routed frame leaves with (SW_MAC_IDX), and routing with the MAC of the
device a route goes out of needs a row per gateway MAC and switch MAC
entry.
Give the entries a callback of their own, set_dmac(), which takes what
an entry holds, struct otto_l3_dmac: the gateway's MAC and the switch
MAC entry, which RTL930x does not take. RTL930x writes the entry
through otto_l3_930x_set_egress_mac() as before. RTL839x writes the
ROUTING row with SW_MAC_IDX from it, so set_egress_mac() is RTL930x's
alone now.
No functional change: every entry still holds a switch MAC entry of 0,
so the rows and the DMAC entries written, and which routes share them,
are as they were. Compile-tested on rtl839x and rtl930x; route-tested
on an HPE 1920-48G (RTL8393) together with the following patch, on
f29dfe25ba.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25822
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
A following patch calls otto_l3_gw_seen() from the handling of a
device's MAC change, which sits above it in l3.c. Move it there,
together with otto_l3_route_inside(), which it calls, so that no
forward declaration is needed. No functional change.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25822
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
An AQR113C can report its copper link over MDIO before it writes the
new rate into the USXGMII code word, which carries 10G while the copper
link is down. phylink reads the speed only when the link comes up, so
the MAC stays at 10G. On an RT-AX89X with a 1G partner on the AQR113C
port this happened in 3 of 20 link-ups, and the port passed no traffic.
Report a rate change in the code word as a link drop, so that phylink
resolves the link again at the new rate. With this change all 20
link-ups ended at 1G; 9 came up at 10G first and were re-resolved
within a second.
Fixes: 05c180511d ("qualcommax: add UNIPHY PCS driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25829
Signed-off-by: Robert Marko <robimarko@gmail.com>
The burst of the port egress rate limiter is clamped to 64000 bytes.
The bucket of the limiter is 16 bits wide and has to hold the burst and
the frame that is sent. When the two no longer fit, the port is not
limited at all, so that clamp only works for frames of up to 1535
bytes.
On an RTL9303 with a limit of 100 Mbit/s, 400 Mbit/s offered and frames
of 9018 bytes, all 400 Mbit/s pass.
Clamp the burst to what leaves room for the largest frame the switch
forwards.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Quinn O'Shea <qoshea@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25831
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Build rt-loader with -O2 and tune the LZMA decoder's inlining decisions
to balance code size and decompression performance.
The existing -O3 setting applies to all loader C sources. In the
standalone decoder comparison used to investigate this change, -O3
substantially increased the generated code size. Simply switching to
-O2 reduced that footprint, but left the frequently used rc_get_bit()
helper out of line, adding function-call and stack-access overhead
throughout range decoding.
Adjust the two helpers independently:
- Declare rc_get_bit() inline to encourage integration into its callers.
This lets the compiler eliminate call overhead and optimise accesses
to the range-coder state, probability values and decoded symbols.
- Mark rc_do_normalize() noinline to retain a shared implementation of
the conditional normalisation path. This limits code duplication as
the surrounding bit-decoding helpers are inlined.
Use the inline keyword rather than always_inline for rc_get_bit().
With the tested compiler, forcing this helper to inline provided no
additional benefit over the simpler declaration.
A standalone comparison with GCC 13.2.0 targeting MIPS32r2/34Kc used
the same synthetic 1 MiB LZMA stream, producing 4 MiB of output. A
generic single-issue in-order model with a 32 KiB instruction cache
and a 16 KiB data cache produced the following results:
- Original -O2: 4,960 bytes of decoder .text; 548,160,936 model cycles.
- Modified -O2: 4,960 bytes of decoder .text; 389,069,748 model cycles.
- Original -O3: 10,496 bytes of decoder .text; 336,140,240 model cycles.
In that setup, the modified -O2 decoder retains approximately 75% of
the cycle reduction achieved by -O3 while using 52.7% less code.
It requires 15.7% more model cycles than -O3. Compared with unmodified
-O2, it reduces model cycles by 29.0% without increasing code size.
All compared variants produced byte-identical output.
These figures describe the standalone decoder experiment, not measured
Realtek hardware performance. The experiment used -fno-pic and
-mno-abicalls; rt-loader retains -fpic and -mabicalls. Actual loader
size and boot-time effects therefore require validation with the
target build and hardware.
The patch changes the optimisation level for the whole loader and
the inlining policy of these two decoder helpers. It leaves the
decompression algorithm, bitstream format and error-handling logic
unchanged.
Assisted-by: ChatGPT (OpenAI GPT-6 Astra)
Link: https://github.com/openwrt/openwrt/pull/25813
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The squashfs images of the TP-Link RE200 v1 and RE210 v1 differ between
builds; the uncompressed kernel of the RE200 one was 271 bytes larger,
from its device tree on:
-00001040: 6d00 0080 00cb 1a9e 0000 0000 0000 006f
+00001040: 6d00 0080 00da 1b9e 0000 0000 0000 006f
The RE210 device tree is exactly 271 bytes larger than the RE200 one, so
the RE200 image carried the kernel of the RE210.
tplink-v1-okli-image puts kernel and rootfs together in
$(IMAGE_ROOTFS).factory or .sysupgrade, a name shared by all devices with
the same rootfs. Both devices are built at the same time, so one can
overwrite the file of the other between cp, cat and mktplinkfw, and an
image can end up with the kernel and device tree of the other device.
Link: https://github.com/openwrt/openwrt/pull/25816
Signed-off-by: Paul Spooren <mail@aparcar.org>
On RTL839x a route through a gateway the switch holds no L2 entry for
gets one invented by otto_l2_nexthop_add(): static, with the don't-care
port. The gateway is then cut off from the switch, and what the route
should forward goes to the CPU instead. Measured on an HPE 1920-48G
(RTL8393), main f29dfe25ba, gateway G on a bridge VLAN behind lan48,
with a permanent neighbour and a MAC the switch had not seen, 8 echo
requests to a destination behind it, forwarding off:
- G's L2 entry was written static, port 63
- G got 0 of 3 replies from the switch; the 8 echo requests reached
the CPU, none reached G
- with the neighbour made dynamic the entry stayed as it was
- with the route removed G got 3 of 3 replies, and the switch learnt
it on port 47
Setting lan48's static move action to forward did not restore it, so
that alone does not explain it; the mechanism is not known.
RTL930x stopped inventing that entry in 138fabb79f ("realtek: l3: do
not invent an L2 entry for a next hop") wherever a route can trap, and
since #25805 an RTL839x route can. Require an entry the switch already
holds on every family: the route traps until the switch learns the
gateway from the traffic the CPU routes, and a later neighbour update
programs it. Nothing asks otto_l2_nexthop_add() to invent an entry any
more, so the flag and the invented entry go. A route trapped for want
of one is now logged on RTL839x as on RTL930x. On RTL839x an L2 entry
that is a next hop already is now pointed at its gateway's ROUTING row
as on RTL930x, one row per gateway MAC since c282dd1f4d.
The same case with this change: no entry written, the route trapped,
G got 3 of 3 replies and was learnt on port 47; the 8 echo requests
reached the CPU and, with forwarding on, G through the kernel, TTL 63.
With the neighbour made dynamic the route forwarded on the learnt
entry, 8 of 8 at G, none at the CPU. The cases from #25805 rerun (two
prefixes in both orders, neighbour loss): same results. Since that run
only the log line and comments changed.
As 138fabb79f says, a route through a permanent neighbour the switch
had not learnt stays with the CPU, since such a neighbour sees no
update: measured here too, it stayed trapped after G was learnt, until
the neighbour was made dynamic. Also as on RTL930x, a route that claims
an entry the switch learnt again after a flush counts itself on top of
the count the flushed entry left, so that entry can stay a next hop
once the route is gone; not tested.
RTL930x: no change, it already required such an entry. RTL838x and
RTL931x have no setup, so their FIB and neighbour events are ignored and
none of this runs there. Compile-tested on rtl930x.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25824
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The NBG7815 cools itself with a GPIO driven fan on TLMM 21. A second
tmp103 sits on the second I2C bus (BLSP QUP4), which the stock firmware
reads as the board temperature, and the stock firmware keeps GPIO 22
high to enable the second fan.
The switching points come from the stock firmware, which controls the
fan from a shell daemon /usr/sbin/fanctld, configured in
/etc/config/fanctld:
config fanctld config
option Enabled '1'
option Delay '20'
option Hits '3'
option TempTrig '108'
option TempClr '85'
fanctld polls every 20 s and starts the fan once any of thermal_zone0
(nss-top), wifi0 or wifi1 has been at or above TempTrig for three
consecutive polls. It stops the fan again only after all three have been
at or below TempClr for three polls:
if [ $temp1 -ge $temp_trig -o $temp2 -ge $temp_trig -o $temp3 -ge $temp_trig ]; then
echo 2
elif [ $temp1 -le $temp_clr -a $temp2 -le $temp_clr -a $temp3 -le $temp_clr ]; then
echo 1
The trip is placed at 85 degC with 5 degC hysteresis, so the fan runs
from 85 degC and stops again at 80 degC, rather than at the stock 108/85:
the SoC hardly reaches 108, so the case gets uncomfortably hot under load
before the fan would ever start, as reported for this device in
https://github.com/openwrt/openwrt/pull/14210
It sits on the CPU cluster rather than on the sensors the stock daemon
polls: the wifi sensors are only reachable through the vendor thermaltool
there, and one zone is enough to drive the fan.
Add the gpio-fan as a cooling device with that trip, enable the second
I2C bus with its tmp103, add the gpio-hog for the second fan enable and
describe the USB VBUS switch on GPIO 32 as a regulator rather than
hogging it.
That regulator carries enable-active-high. For regulator-fixed, gpiolib
ignores the flag in the GPIO specifier and takes the line as active low
without that property, so the regulator would drive GPIO 32 low at probe
- logged as "enforce active low on GPIO handle" - while the stock
firmware holds the line high.
The AQR PHY is deliberately left out of the cooling maps: its driver
rejects the low trip the thermal core installs by default, so a thermal
zone bound to it fails to set its trips.
Co-developed-by: Semih Baskan <strst.gs@gmail.com>
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Signed-off-by: André Valentin <avalentin@marcant.net>
The front panel of the NBG7815 carries nine RGB LEDs, driven by three TI
LP5569 controllers on the first I2C bus. The stock firmware keeps GPIO 60
high to enable the LED board.
The third controller sits at 0x40, where the stock firmware pokes two
registers directly instead of binding a driver, and the board schematics
call it an LP5009. It answers to the lp5569 register layout though: a
write to the pwm registers at 0x16 lights the LEDs, while the lp50xx
driver only ever got -EIO. Verified on the device by reading back the
registers and by the LEDs actually turning on.
Placement and colours were measured with a camera pointed at the front bar,
one frame per lit LED against a dark frame. LED1 to LED6 walk through the bar
monotonically, so the two controllers form one continuous chain: 0x32
ascending, 0x35 descending, which is also the channel order the stock
zled_ctrl script uses. Red, green and blue each come out as the dominant
channel on all three controllers.
The three groups of the controller at 0x40 light the same spot near the
middle of the bar instead, each with about twice the output of a bar segment,
so they feed one brighter element together rather than three segments of
their own.
Channel numbers are per controller. Getting that wrong is quiet but
destructive: lp55xx_multicolor_brightness() adds the number to the pwm
register base without checking it against the channel count, so the
writes land in the current registers of other channels instead.
Add the controller nodes with the channel mapping and the LED currents
of the stock firmware, the gpio-hog for the LED board enable, and set
LED7 to white through board.d. That is the brighter element in the middle
rather than one end of the bar, and it is the one the stock firmware keeps
driving in every state through its two register writes to 0x40.
The same LED is wired to the led-running and led-upgrade aliases, so
diag.sh turns it on once the system is up and blinks it while a sysupgrade
runs. Measured with a camera at 30 fps: 36 cycles of 200 ms on and 200 ms
off for the duration of the flash.
led-boot and led-failsafe are deliberately absent. Both states are set
from preinit, before the i2c driver for the controller is loaded, so the
LED does not exist yet and led_set_attr() silently skips it - confirmed by
recording a boot, where the LED stays dark and then comes on in one step.
The aliases need a "label" on the multi-led node: get_dt_led() looks for
label, then chan-name, and otherwise composes a name from color and
function, which would be "rgb:" here. The lp55xx driver only reads "label"
from the controller node, so it does not affect the class device name.
Signed-off-by: André Valentin <avalentin@marcant.net>
Rename struct rtldsa_vlan_info to struct otto_vlan_info and update
all references to match the otto_vlan_ namespace.
No functional changes intended.
Assisted-by: ChatGPT (OpenAI GPT-6 Astra)
Link: https://github.com/openwrt/openwrt/pull/25817
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The statistics functions already use the otto_stats_ prefix, while
the associated structure types and variables still use rtldsa_.
Rename the counter and MIB structure types, per-SoC MIB lists and
descriptors, and polling interval macros to match the module's
namespace. Update all declarations and references in the shared
header and the four SoC configurations.
No functional changes intended.
Assisted-by: ChatGPT (OpenAI GPT-6 Astra)
Link: https://github.com/openwrt/openwrt/pull/25817
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Shiji Yang
Lars Gierth
Rosen PenevandClaude Opus 5.5
Gennaro Cimmino
Marc Strämke
Quinn O'Shea
Jonas Jelonek
Hsiu-Chi Tsai
Julius Bairaktaris
Markus Stockhausen
Paul Spooren
André Valentin