Received-SPF: pass (google.com: domain of linux-wireless+bounces-1354-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sat, 30 Dec 2023 19:37:56 +0000
To: =?utf-8?Q?Michael_B=C3=BCsch?= <m@bues.ch>
From: 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
Message-ID: <87bka7wkfm.fsf@protonmail.com>
In-Reply-To: <20231230184113.3ecfed4f@barney>
References: <20231230045105.91351-1-sergeantsagara@protonmail.com> <20231230045105.91351-3-sergeantsagara@protonmail.com> <CAGRGNgWYLTmRfvw94Ok_FfcEVGPa0tRg-ELxkD8K6nxTTNZ9jg@mail.gmail.com> <20231230144036.7f48b739@barney> <878r5bk3x9.fsf@protonmail.com> <20231230184113.3ecfed4f@barney>
Feedback-ID: 26003777:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, 30 Dec, 2023 18:41:13 +0100 Michael B=C3=BCsch <m@bues.ch> wrote:
> [[PGP Signed Part:Undecided]]
> 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=C3=BCsch <m@bues.ch> wrote=
:
>> > [[PGP Signed Part:Undecided]]
>> > On Sat, 30 Dec 2023 18:48:45 +1100
>> > Julian Calaby <julian.calaby@gmail.com> wrote: =20
>> >> > --- 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 =3D skb_get_queue_mapping(=
skb);
>> >> > -               ieee80211_stop_queue(dev->wl->hw, skb_mapping);
>> >> > +               if (dev->qos_enabled)
>> >> > +                       ieee80211_stop_queue(dev->wl->hw, skb_mappi=
ng);
>> >> > +               else
>> >> > +                       ieee80211_stop_queue(dev->wl->hw, 0);   =20
>> >>=20
>> >> Would this be a little cleaner if we only look up the queue mapping i=
f
>> >> QOS is enabled? I.e. =20
>> >
>> > 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. =20
>>=20
>> 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.

I did some git analysis, and I actually believe that this issue has been
present since the commit e6f5b934fba8 ("b43: Add QOS support"). Before
then, non-QOS would not trigger this issue. There is a cosmetic change
after this commit, b27faf8ebf25 ("b43: Rename the DMA ring pointers"),
but this change does not introduce the issue (but makes it more
obvious). I think the reason nobody has ever reported this is that even
when the warnings are triggered, everything appears to work fine. I
think therefore the two options are the following.

1. Remap the BE queue to 0 instead of the BK queue.
2. Use this kind of conditional to handle the mapping when QoS is
   disabled.

--
Thanks,

Rahul Rameshbabu