On 03/28/2017 03:57 PM, Thierry Reding wrote: > From: Thierry Reding <tred...@nvidia.com> > > Even if hardware supports multiple queues, software can choose to only > use a subset of them. Make sure we never try to access uninitialized > queues. > > Signed-off-by: Thierry Reding <tred...@nvidia.com> > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index 106ace3781b3..ec5bba85c529 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -3423,7 +3423,7 @@ static int stmmac_poll(struct napi_struct *napi, int > budget) > struct stmmac_rx_queue *rx_q = > container_of(napi, struct stmmac_rx_queue, napi); > struct stmmac_priv *priv = rx_q->priv_data; > - u32 tx_count = priv->dma_cap.number_tx_queues; > + u32 tx_count = priv->plat->tx_queues_to_use; > u32 chan = rx_q->queue_index; > u32 work_done = 0; > u32 queue = 0; >
Thanks Thierry, but this look like an equivalent patch to Joao's "net: stmmac: fix number of tx queues in stmmac_poll" which I already used during bisecting to avoid random crashes in stmmac_tx_clean. Have you noticed random RX brokenness after boot in recent linux-next tags? It feels like it might trigger more often after a cold boot, but that could just be my brain seeing patterns that aren't really there :)
