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

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Mar 23, 2026 at 04:45:18PM +0000, Daniel Golle wrote:
> That means the driver *does* have to track a mapping between DSA
> bridges and hardware/firmware bridges on that specific switch somehow.

That's correct. From DSA's perspective, it's not an mxlbridge, it's just
a bridge with at least one DSA switch port under it, which is given a
kernel-wide identifier. The ports can hold a single reference to the
common bridge, but the common bridge cannot hold a single back-reference
to individual ports. And holding multiple references would severely
complicate the implementation.

Even if you don't implement accelerated cross-switch bridging, you can
still have two mxl ports belonging to different switches that are both
put by the user under the same bridge. And both switch driver instances
would want to allocate a potentially different bridge ID, and surely
maintain a different portmap, for that same bridge.

> 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@redhat.com/

The API was intended so that you could either use the bridge.num directly,
transform it through some linear formula or as an index into a privately
maintained array of data structures with switch-specific meaning.

I didn't question why you maintain a parallel list of dynamically
allocated mxlbridge structures instead of just having an array of
MXL862XX_MAX_BRIDGES * sizeof(u16) for the bridge identifiers, plus
maintain a separate portmap instead of walking through the DSA data
structures, but now that Paolo brought it up: why?

I see in v6 you're halfway there with the conversion, you got rid of the
portmap and you could just use the array for the rest.