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