b43-dev.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Büsch" <m@bues.ch>
To: Rahul Rameshbabu <sergeantsagara@protonmail.com>
Cc: Julian Calaby <julian.calaby@gmail.com>,
	Kalle Valo <kvalo@kernel.org>,
	linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH wireless 2/5] wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
Date: Sat, 30 Dec 2023 18:41:13 +0100	[thread overview]
Message-ID: <20231230184113.3ecfed4f@barney> (raw)
In-Reply-To: <878r5bk3x9.fsf@protonmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2045 bytes --]

On Sat, 30 Dec 2023 17:15:18 +0000
Rahul Rameshbabu <sergeantsagara@protonmail.com> wrote:

> On Sat, 30 Dec, 2023 14:40:36 +0100 Michael Büsch <m@bues.ch> wrote:
> > [[PGP Signed Part:Undecided]]
> > On Sat, 30 Dec 2023 18:48:45 +1100
> > Julian Calaby <julian.calaby@gmail.com> 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/

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

  reply	other threads:[~2023-12-30 17:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-30  4:51 [PATCH wireless 0/5] wifi: b43: Various QoS-related fixes Rahul Rameshbabu
2023-12-30  4:51 ` [PATCH wireless 1/5] wifi: b43: Correct OpenFW QoS capability warning conditional Rahul Rameshbabu
2023-12-30 13:34   ` Michael Büsch
2023-12-30 17:17     ` Rahul Rameshbabu
2023-12-30  4:51 ` [PATCH wireless 2/5] wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled Rahul Rameshbabu
2023-12-30  7:48   ` Julian Calaby
2023-12-30 13:40     ` Michael Büsch
2023-12-30 17:15       ` Rahul Rameshbabu
2023-12-30 17:41         ` Michael Büsch [this message]
2023-12-30 19:37           ` Rahul Rameshbabu
2023-12-30  4:51 ` [PATCH wireless 3/5] wifi: b43: Stop/wake correct queue in PIO " Rahul Rameshbabu
2023-12-30 18:04   ` Larry Finger
2023-12-30 19:43     ` Rahul Rameshbabu
2023-12-30 22:23       ` Larry Finger
2023-12-31  0:02         ` Rahul Rameshbabu
2023-12-31  9:33           ` Michael Büsch
2023-12-31 17:29             ` Rahul Rameshbabu
2023-12-30  4:51 ` [PATCH wireless 4/5] wifi: b43: Stop correct queue in DMA worker " Rahul Rameshbabu
2023-12-30  4:51 ` [PATCH wireless 5/5] wifi: b43: Support advertising lack of QoS capability Rahul Rameshbabu
2023-12-30 13:45   ` Michael Büsch
2023-12-30 17:10     ` Rahul Rameshbabu
2023-12-30 17:43       ` Michael Büsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231230184113.3ecfed4f@barney \
    --to=m@bues.ch \
    --cc=b43-dev@lists.infradead.org \
    --cc=julian.calaby@gmail.com \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sergeantsagara@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).