Re: [PATCH net-next v6 2/4] net: dsa: add bridge member iteration macro and port mask helper

[Daniel Golle]

On Mon, Mar 23, 2026 at 06:31:04PM +0200, Vladimir Oltean wrote:
> On Mon, Mar 23, 2026 at 02:29:41AM +0000, Daniel Golle wrote:
> > I wasn't aware of the similar and equally named function in
> > yt921x.c[1]
> 
> Yeah, I did request from the beginning for it to be moved to
> include/net/dsa.h, but I didn't follow through with the request (I guess
> I forgot):
> https://lore.kernel.org/netdev/20250825212357.3acgen2qezuy533y@skbuf/
> 
> > Patchwork CI has loudly uncovered it and I've learned my lesson to
> > always test an all-y build when changing even the most innocent
> > looking things which technically may affect other drivers.
> 
> Since all DSA drivers are all in the same folder, technically you may be
> excused if you just enable all those when working on infra, instead of
> allyesconfig.
> 
> > I'll move that function as-is, in a dedicated commit, to
> > include/net/dsa.h as an inline function instead of the helper
> > suggested here.
> > 
> > A second commit will introduce the new helper macro
> > dsa_switch_for_each_bridge_member (modified to use (struct net_device
> > *) as parameter instead of (struct dsa_bridge *), and make use of it
> > in dsa_bridge_ports().
> > 
> > I'm also planning to introduce dsa_bridge_for_each_member macro in
> > addition to that which works on (struct dsa_bridge *) and uses
> > dsa_switch_for_each_bridge_member.
> 
> I don't like the dsa_bridge_for_each_member() name. You are likely
> not considering cross-chip bridging, where a bridge spans multiple
> dsa_switch structures. That is also a serious reason why your
> bridge->priv design is not viable (two switches can't lay their eggs
> in the same basket without overwriting each other).

That means the driver *does* have to track a mapping between DSA
bridges and hardware/firmware bridges on that specific switch somehow.

Or is there another existing structure in DSA I'm not aware of and
which could be used to implement Paolo's suggestion:

https://lore.kernel.org/netdev/fe46d64b-1b12-48b6-b663-e7d5122b7b8a@xxxxxxxxxx/