Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support

[Luke Howard]

> On 3 Jun 2026, at 12:41 pm, Andrew Lunn <andrew@xxxxxxx> wrote:
> 
>> 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