Re: [PATCH net-next 5/8] net: dsa: lan9645x: add bridge support

[Vladimir Oltean <olteanv@gmail.com>]

On Tue, Mar 03, 2026 at 05:08:10PM +0100, Jens Emil Schulz Ostergaard wrote:
> On Tue, 2026-03-03 at 16:20 +0200, Vladimir Oltean wrote:
> > 
> > On Tue, Mar 03, 2026 at 01:22:31PM +0100, Jens Emil Schulz Østergaard wrote:
> > > We support a single bridge device.
> > 
> > Why? I keep seeing this from Microchip engineers. Having two
> > VLAN-unaware bridges on different sets of ports is a perfectly valid use
> > case. On Ocelot I took the driver from a state where it had an identical
> > implementation to yours and I made it handle multiple bridges. I don't
> > see where's the problem.
> 
> The main reason is that is what we support in other drivers such as sparx5,
> lan969x and lan966x. I saw your solution for Ocelot, but I could not think
> of the use case, where you would not just use vlans on a single bridge to
> isolate forwarding domains. But I may be missing something.

I already said the use case, VLAN-unaware bridging, where it transports
VLAN-tagged packets from one port to another without filtering based on
the VLAN tag.

You can't replicate that with a bridge with vlan_filtering=1, because it
would then stumble over VLAN-tagged packets which you'd need to add to
the VLAN table, otherwise they'd be dropped. And then you couldn't have
the same VLANs being transported in bridge A as the VLANs that are
transported by bridge B, because you would allow inter-bridge forwarding.
It's just not the same thing.

> The same solution would work here, but the bridges can not be vlan-aware.

Yeah, hardware limitation, there it makes sense to have a restriction in place.