Re: [PATCH wireless 2/5] wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

Michael Büsch <[email protected]> Sat, 30 Dec 2023 18:41:13 +0100

Newsgroups	org.infradead.lists.b43-dev,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless
Message-ID	<20231230184113.3ecfed4f@barney>

On Sat, 30 Dec 2023 17:15:18 +0000
Rahul Rameshbabu <[email protected]> wrote:

> On Sat, 30 Dec, 2023 14:40:36 +0100 Michael Büsch <[email protected]> wrote:
> > [[PGP Signed Part:Undecided]]
> > On Sat, 30 Dec 2023 18:48:45 +1100
> > Julian Calaby <[email protected]> wrote:  
> >> > --- a/drivers/net/wireless/broadcom/b43/dma.c
> >> > +++ b/drivers/net/wireless/broadcom/b43/dma.c
> >> > @@ -1399,7 +1399,10 @@ int b43_dma_tx(struct b43_wldev *dev, struct sk_buff *skb)
> >> >             should_inject_overflow(ring)) {
> >> >                 /* This TX ring is full. */
> >> >                 unsigned int skb_mapping = skb_get_queue_mapping(skb);
> >> > -               ieee80211_stop_queue(dev->wl->hw, skb_mapping);
> >> > +               if (dev->qos_enabled)
> >> > +                       ieee80211_stop_queue(dev->wl->hw, skb_mapping);
> >> > +               else
> >> > +                       ieee80211_stop_queue(dev->wl->hw, 0);    
> >> 
> >> Would this be a little cleaner if we only look up the queue mapping if
> >> QOS is enabled? I.e.  
> >
> > No. It would break the other uses of skb_mapping.
> >
> > But I am wondering why skb_mapping is non-zero in the first place.
> > I think the actual bug might be somewhere else.  
> 
> Right, skb_mapping is used to map to the correct software structures DMA
> mapped to the device. The reason the mapping for the best effort queue
> (the default/defacto when QoS is disabled) is not zero is due to the way
> initialization of the queues/rings occurs in the driver. The best effort
> queue is mapped as the third queue, which leads to this issue when QoS
> is disabled. Would it make more sense to change the mappings in
> initialization such that the best effort queue is by default mapped to
> zero, so we would not need such conditionals?

Maybe it is a good idea to find the patch that broke non-QoS.
That possibly helps to understand the situation.

Non-QoS used to work just fine.

-- 
Michael Büsch
https://bues.ch/

_______________________________________________
b43-dev mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/b43-dev

signature.asc (application/pgp-signature, 833 B)