On 3 Jun 2026, at 12:41 pm, Andrew Lunn [off-list ref] wrote:

quoted

We could add (e.g.) bridge_setup_tc to dsa_switch_ops, which (in the
mv88e6xxx implementation) could validate the bridge contained all
user ports. But it would not be possible to block a port from
leaving as port_bridge_leave cannot return an error, and tearing
MQPRIO config down silently would be a different sort of bad.

There can be multiple bridges, even as far as one bridge per port.

Right, per the above mv88e6xxx would return -EOPNOTSUPP if the bridge did not contain all DSA user ports. But without a means to block the removal of ports from bridges it would not be possible to maintain this invariant.

For switch wide properties, you basically have to allow the first user
to configure it, refcount additional users get added and removed, and
only allow the last user to change it.

Indeed, that’s what this series does. But it comes with the discussed caveat that ports without MQPRIO (whether or not they are part of a bridge) implicitly inherit the global FPri to QPri mapping. I think that is  acceptable given that users should have no expectaitons about the default mapping, but others may disagree.

The alternative is return -EOPNOTSUPP, and let the kernel do it in
software, if a user wants something different to the global
setting. The hardware is only there to accelerate what Linux can
already do in software. That is the model we use.

Yes, this is how it is implemented.

Luke