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

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:

quoted

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.

quoted

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/ (local)

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.