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 11:15:36PM +0200, Vladimir Oltean wrote:
> 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@xxxxxxxxxx/
> 
> 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?

The firmware requires bridges to be allocated, and the bridge
allocation firmware API returns the ID we got to use.

Maintaing a simple array ((ds->max_num_bridges + 1) * sizeof(u16))
to map DSA bridge num to firmware bridge ID in the driver works
fine, of course.

Regarding the request not to maintain a separate portmap for each
bridge (which was my initial approach) but instead walk through DSA
data:

My guess was the intention is to avoid duplciating data, as in: if
there is only one copy, we can be sure it's not stale or
out-of-sync...? But that's just my guess, only Paolo can tell his
reasons for having requested that.

> 
> 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.

Ack. I'll do that and post v7.