[cid] 7b49c9cf4b77a69f03297f515c89e94f21c9b1c0
ARM: dts: qcom: change labels to lower-case
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Hans Ulli Kroll <linux@ulli-kroll.de>
Signed-off-by: Lars Gierth <larsg@systemli.org>
Link: https://github.com/openwrt/openwrt/pull/25854
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The prefix row placement is common to RTL839x and RTL930x, but where an
IPv6 entry sits is not: an RTL839x PIE rule matches a whole IPv6
destination in any row, while an RTL930x entry spans three rows and may
only start on two rows of every eight. otto_l3_v6_row() and
otto_l3_v6_slot() chose between the two layouts through use_l3_tables,
which says how a family routes, not how its table is laid out.
Give the families v6_slot_to_row() and v6_row_to_slot() and move each
layout next to its row mover. Ordering, insertion, compaction and the
capacity and IPv4/IPv6 collision checks stay common, and keep calling
the same two helpers, which now ask the family. The common code calls
them only for a family with a row mover.
The formulas move unchanged. Built on the host from l3.c as it is, the
placement code before and after this change maps every slot and row of
both layouts alike, and runs 160000 random IPv4 and IPv6 insertions and
removals, past a full table on both families, with the same rows and
the same moves; a one-line mutation planted in each of the four
callbacks makes the results differ. On an HPE 1920-48G (RTL8393) an
IPv6 test round passes 20 of 20 checks, among them a /48 and a /64
inserted in both orders and IPv4 and IPv6 routes side by side, the
routes of those checks forwarded in hardware to the right gateway.
RTL930x is 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/25868
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The Herospeed RV1126 IMX415 "Base" is an IP camera built on a Rockchip
38x38 V10 EMMC DDR3 board, which is also found in cameras of other
makes and is therefore described by a separate dtsi. The stock firmware
identifies itself as ONVIF manufacturer "HeroSpeed", firmware family
RV1126_IMX415_BASE. This adds the 32-bit armv7 subtarget for the
Cortex-A7 based RV11xx SoCs. The camera keeps its stock U-Boot, which
boots an Android boot image from one of two boot/system slots.
Hardware
--------
SoC: Rockchip RV1126, 4x Cortex-A7
RAM: 1 GiB DDR3
Flash: eMMC, 8 GB class, two boot/system slots
Ethernet: 1x 10/100 Mbit/s, JL1101 PHY on RMII
Sensor: Sony IMX415, 4 lane MIPI CSI-2
RTC: PCF8563
LEDs: white illumination LEDs on one PWM output (V4L2 flash)
Buttons: none
UART: 1.8 V TTL on UART2, 1500000 baud 8N1, 90-degree JST-SH connector
at the bottom edge of the board, facing the edge and hidden underneath
the MIPI CSI cable
Power: PoE (IEEE 802.3af) or 12 V 1 A DC through the barrel connector
on the cable whip
Installation
------------
1. Open the web interface of the stock firmware (192.168.1.168 by
default) and log in as admin.
2. Upload openwrt-rockchip-armv7-herospeed_rv1126-imx415-squashfs-
factory-RV1126_IMX415.fls on the firmware upgrade page.
3. The camera reboots into OpenWrt at 192.168.1.1.
Later upgrades use the sysupgrade image, which is written to the
inactive slot. The stock firmware can be restored from OpenWrt with
"sysupgrade -F -n" and the original .FLS file.
MAC address
-----------
eth0 uses the label MAC, stored as MAC=xx:xx:xx:xx:xx:xx in net.conf on
the ext4 "param" partition. U-Boot passes a different, derived address
to Linux, which is replaced by the stored one.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add RV1126 support (USB2 PHY and DWC3, TSADC, clocks, I2C and SPI,
cpufreq, I2S and PDM, VICAP, MIPI CSI-2 D-PHY, VPU, RGA, hwrng) and
describe the SoC in rv1126.dtsi. Import and rewrite the unmerged
crypto driver for RK3568 and RK3588 by Corentin Labbe (AES, hashes);
its RK3568 and RK3588 support is untested. Add a newly written driver
for flash LEDs driven by a PWM channel.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport the pixel clock sampling mode defines of the video-interfaces
dt-bindings header, which the rk3568 vicap binding example already
uses. The Rockchip RV1126 capture nodes refer to the same header.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The pci and pcie features and the Image kernel target describe the
64-bit RK33xx/RK35xx boards, not the Rockchip family as a whole. Set
them in the armv8 target.mk so that a 32-bit ARM subtarget can build a
zImage and does not advertise PCIe.
The feature set and kernel targets of armv8 stay as they were.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The use map counts the routes that forward through an L2 unicast entry
in seven bits. At 127 the count stops, and an entry that got there is
never released: when its routes are gone it keeps its next hop flag
until the switch restarts. RTL930x takes 512 prefix and 1536 host
routes, so more than 126 through one gateway is an ordinary table.
Give the count fifteen bits, more than the routes of any family. The
map grows from one to two bytes per entry.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Quinn O'Shea <qoshea@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25859
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
A route with no gateway keeps the unspecified address where its gateway
would be, 0.0.0.0 or ::, and so does the route of each address of the
switch. Their rows trap to the CPU. The kernel accepts a neighbour at
that address when one is added by hand, and otto_l3_nexthop_update(),
which matches a neighbour on the gateway and the device recorded for
each route, takes it for the gateway of such routes and can turn their
rows into forwarding ones. Leave such a neighbour alone: it is the
gateway of no route.
HPE 1920-48G (RTL8393), host B on VLAN 3, 10.99.0.0/16 dev switch.3,
and
ip neigh add 0.0.0.0 lladdr <MAC of host B> dev switch.3 nud permanent
Without the change the row of 10.99.0.0/16 forwarded 8 of 8 echo
requests from another VLAN to host B with TTL 63, none reached the CPU,
and the rows of the switch's addresses and on-link prefixes on switch.3
turned to forwarding as well: a host on another VLAN got no answer from
10.91.3.1, 0 of 3. With :: on IPv6 the trap rows of fd00:90:3::1/128,
fd00:90:3::/64 and 2001:db8:99::/48 went through the same update and
took a packet counter each, but kept trapping here.
With the change the neighbour event still arrives and changes nothing:
the rows keep trapping and take no counter, the 8 echo requests reach
the CPU, and the switch answers on 10.91.3.1 and fd00:90:3::1, 3 of 3.
A route through a gateway, measured before the neighbour was added,
forwards in hardware on both, 8 of 8 with TTL and hop limit 63.
RTL930x is compile-tested only; families without an L3 setup never
queue the neighbour event.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25863
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
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>
Hans Ulli Kroll
Lars Gierth
Gennaro Cimmino
Daniel Golle
Quinn O'Shea
Shiji Yang
Rosen PenevandClaude Opus 5.5
Marc Strämke
Jonas Jelonek
Hsiu-Chi Tsai