Re: [PATCH net v4 4/4] net: dsa: ks8995: Add stub bridge join/leave

[Vladimir Oltean <olteanv@gmail.com>]

On Thu, Mar 26, 2026 at 10:57:35AM +0100, Linus Walleij wrote:
> Implementing ks8995_port_pre_bridge_flags() and
> ks8995_port_bridge_flags() without port_bridge_join()
> is a no-op.
> 
> This adds stubs for bridge join/leave callbacks following
> the pattern of drivers/net/dsa/microchip/ksz_common.c:
> as we have STP callbacks and these will be called right
> after bridge join/leave these will take care of the
> job of setting up the learning which is all we support.
> 
> Fixes: a7fe8b266f65 ("net: dsa: ks8995: Add basic switch set-up")
> Reported-by: Vladimir Oltean <olteanv@gmail.com>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---

Yes, but there are important differences to ksz_update_port_member() too.
For one, ksz_common keeps track of which port belongs to which bridge
(dsa_port_bridge_same), in order to separate forwarding domains, and
ks8995_port_stp_state_set() doesn't. So I have my doubts that the
complexity of the driver is currently sufficient to behave in a
satisfactory manner. If lan0 and lan1 were under br0 while lan2 and lan3
were under br1, I don't see what would prevent lan0 <-> lan2 forwarding.