Re: [PATCH net] net: stmmac: preserve real_num_tx_queues on mqprio setup failure

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 8 Sep 2026 12:12:43 +0200 Lorenzo Bianconi wrote:
> > So dev->num_tc goes back to 0 immediately after the driver restored it, and
> > skb_tx_hash() ignores tc_to_txq and prio_tc_map when num_tc is 0.  On a
> > failing "tc qdisc replace" over an already offloaded mqprio, does the still
> > grafted old qdisc lose its priority classification anyway?  
> 
> I think in a error condition, the driver is supposed to restore the previous
> overwritten values, then it is up to qdisc layer to manage the error condition.

I'd translate all the AI complaints to a basic confusion about what
exactly is the problem you're fixing and how it can be triggered.
A better commit message may be sufficient. An example of sequence of
tc commands which used to lead to loss of config / broken device and
now does not would go a long way.

> > For taprio, the new error also takes the disable label, which clears
> > priv->est->enable and reprograms EST, so the schedule that was just
> > installed is torn down.  Is that intended for configurations that used to be
> > accepted, for example:
> > 
> >   tc qdisc replace dev eth0 root taprio ... queues 2@0 2@2 ... fp E P
> > 
> > Also, the two remaining users that still ignore the now meaningful return
> > value, the taprio disable path and stmmac_reset_tc_mqprio(), were not
> > updated.  Should they be?

This sounds relevant as well.