On 11/02/2026 12:02, Daniel Golle wrote:
On Wed, Feb 11, 2026 at 11:44:12AM +0100, Caleb James DeLisle wrote:
On 11/02/2026 11:26, Daniel Golle wrote:
On Wed, Feb 11, 2026 at 11:13:26AM +0100, Caleb James DeLisle wrote:
On 10/02/2026 23:12, Benjamin Larsson wrote:
If I understand correct, the ref SDK just sets up a transparent bridge
and lets the packets flow through? If that is correct is that an option
here?
When use_soc_lan is unset, this is what happens. When use_soc_lan is set, it
does a bunch of highly awkward stuff to add support for one extra port on
the internal switch. It's an option, probably to treat the internal switch
as part of the eth driver - however this will not work on EN7526C which no
external switch, internal is exposed.
And IMO we should not stack stags. If it is possible to pass stags
through with the pass-through bit intact it should be possible to
address all ports on both switches with just one stag.
I was hoping the PT_OPTION PVC bit would set the stag pass through bit
on incoming frames.
Stacking stags does potentially have a performance penalty in the tag parser
- I say "potentially" because it's already walking a list which could be an
array index, and even 2 array indexes is faster than what we have now.
But trying to use the PT bit as designed makes it impossible to
differentiate between a packet that came from port N of the external switch
and a packet that came from port N of the internal. Vendor code doesn't
support having the same port number active on both internal and external, if
you try it will quietly overwrite the switch_port_map entry in
init_ethernet_port_map(), so I surmise this is a real silicon bug, not a
misconfiguration on my end.
But (so far), stacking tags seems to work, so I would much prefer it to
inter-switch rules, i.e. "you can't enable this port in the DT because you
have one with the same number on the other switch".
So if the vendor SDK doesn't allow using the same port number on both,
the on-die and the MCM switch, that means there won't be any boards
around doing that, right? Nobody is designing new boards with this
silicon at this point, all existing boards had to adhere to those rules.
Hence I don't see why the extra overhead of stacked special tags would
be worth it, especially also given that stacked special tags also won't
work with the hardware offloading PPE/HWNAT, and likely also break other
stuff such as TX checksum offloading.
BTW Vendor code (see: TCSUPPORT_MULTI_SWITCH_EXT) suggests there are boards
with multiple external switches. Probably a board integrator hung another
7530 off of one of the RGMII interfaces. Per my reading, vendor code falls
back on VLANs, giving up on the stag entirely. I haven't confirmed that
transmit works yet, but assuming it does, stacked stags should Just Work in
this use case whereas the PT bit clearly would not.
Have you seen any boards actually using an additional (ie. third) MT7530
connected as external IC? If this feature is only a theoretical option
which none of the board markers choose to implement I think it's worth
ignoring it and not supporting it upstream, especially if the vendor SDK
just uses the swconfig driver with VLANs rather than DSA.
Okay, I'll put a "no port reuse" check in mt7530.c and in tag_mtk.c I'll
just the dsa_conduit_find_user() with a relaxed walker that ignores switch
ID, then make mtk_tag_xmit() set the PT bit if switch ID is non-zero.
Chaining will support 1 downstream switch on port 5, and any port used on
one switch cannot be used on the other.
In case the MCM switch is being used to provide user ports, are any
ports of the on-die switch other than the CPU port and the port
connecting the MCM switch used as well?
Theoretically (vendor code), and I think the pins are exposed, but I
don't own any board that uses them.
If using the MCM switch anyway effectively turns the on-die switch into
a "2 port switch" only forwarding between those 2 ports, it would be
worth investigating if MTRAP register can be used similar like on MT7530
(on MT7531 it doesn't exist), see mt7530_setup_port5().
Not sure what you're getting at re MTRAP, but if you're talking about
making the SoC switch into a bridge, that should be possible with an
ACL. However, SoC switch must still be supported because EN7526C has no
MCM (and that's a popular SoC, I have boards with it).
Then question is: If we implement a pass-through switch, is that a
different driver? I guess it doesn't register as DSA. What is it in the
DT? Do we still reset it and tune TRGMII? Would need to copy:
mt7530_setup_port6, mt7530_setup_port5, all of the MDIO bus stuff
(mt7531_ind_c22_phy_read, mt7531_ind_c22_phy_write), and some of
mt7530_setup.
I guess it could also be a special case of mt7530.c which doesn't
register as DSA, but that seems like it would make the code quite a bit
more weird and confusing.
Here's the stacked stag implementation for reference, it currently works
though TRGMII is unstable:
https://github.com/cjdelisle/econet_eth/commit/285f02a16fed9b2bfadf9ba950998e3e305ffeef
1. mt7530_post_register() avoids a deadlock: dsa_register_switch() ->
mt753x_setup() -> mt7530_setup_mdio() -> devm_of_mdiobus_register() ->
mt7530_probe() -> dsa_register_switch()
2. mt753x_available_ports() = user ports and DSA link ports
3. en751221_mac_port_get_caps() will be corrected
4. tag-mtk.c is made recursive
5. Tons of tuning which (I assume) is needed because these run at
362.5Mhz, and even now the TRGMII link is still not very stable
6. Tons of debug logging which will obviously be removed before making a
patchset
Changing to PT based chaining as I said earlier is not that big a deal.
Majority of the code isn't chaining related but rather tuning.
Thanks,
Caleb
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
