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? 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(). _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
