From: Ping-Ke Shih <pkshih@realtek.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
Bitterblue Smith <rtl8821cerfe2@gmail.com>
Cc: Sascha Hauer <sha@pengutronix.de>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH 2/2] wifi: rtw88: Avoid using macid 0 in AP mode
Date: Mon, 19 Aug 2024 02:59:24 +0000 [thread overview]
Message-ID: <e8d3c81a47de44e1ba7df08b9de826ee@realtek.com> (raw)
In-Reply-To: <6d1667d2-c86f-4b80-bb32-9ba01164480b@maciej.szmigiero.name>
Maciej S. Szmigiero <mail@maciej.szmigiero.name> wrote:
> On 31.07.2024 14:20, Bitterblue Smith wrote:
> > On 31/07/2024 03:47, Ping-Ke Shih wrote:
> >> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>> On 30/07/2024 09:33, Ping-Ke Shih wrote:
> >>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>>>>
> >>>>> In AP mode, the firmware stops transmitting beacons if it receives
> >>>>> H2C_CMD_RA_INFO for macid 0.
> >>>>>
> >>>>> Leave macid 0 unused in AP mode. Macid 1 is already reserved for
> >>>>> broadcast/multicast. Assign macid 2 to the first connected client.
> >>>>
> >>>> Seemingly we missed to set mac_id in TX desc for a long time.
> >>>>
> >>>> +#define RTW_TX_DESC_W1_MACID GENMASK(7, 0)
> >>>> #define RTW_TX_DESC_W1_QSEL GENMASK(12, 8)
> >>>> #define RTW_TX_DESC_W1_RATE_ID GENMASK(20, 16)
> >>>>
> >>>> The mac_id should be from rtwvif->mac_id or si->mac_id according to
> >>>> operating mode and role.
> >>>>
> >>>> And I suppose mac_id assignment for AP is mac_id 0 for broadcast/multicast, and
> >>>> other mac_id can be used by connected stations regularly.
> >>>>
> >>>
> >>> What about the concurrent AP + station scenario? Will the
> >>> station vif use the next available macid, whatever that is?
> >>> Just wondering, I don't use concurrent mode.
> >>
> >> My basic idea is to assign mac_id to each vif when adding vif. For station mode,
> >> sta->mac_id will reuse vif->mac_id. For AP mode, I will dynamically allocate an
> >> sta->mac_id to a station, and vif->mac_id is to send broadcast/multicast packets
> >> that are not belong to a sta. For example,
> >>
> >> vif->mac_id sta->mac_id
> >> vif0 (STA mode) 0 0
> >> vif1 (AP mode) 1 2...
> >>
> >>
> >>>
> >>> Also, do you mean that you will do all this? It's not clear to me.
> >>
> >> I can do it. Or are you interested in this?
> >>
> >
> > No, no, it's all yours. :)
> >
>
> It would be nice to have either this submitted fix or alternative one merged soon
> since the AP mode is completely broken otherwise (at least on RTL8821CU).
I have sent a patch [2] to replace this one, but still needs
patch 1/2 "wifi: rtw88: Fix USB devices not transmitting beacons". [1]
I have tested [1] + [2] can work on PCI devices.
Can anyone help to test if [1] + [2] also works on USB devices?
[1] https://lore.kernel.org/linux-wireless/9174a776-4771-4351-85fa-476e240d8ace@gmail.com/
[2] https://lore.kernel.org/linux-wireless/20240819025248.17939-1-pkshih@realtek.com/T/#u
next prev parent reply other threads:[~2024-08-19 2:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-28 22:49 [PATCH 1/2] wifi: rtw88: Fix USB devices not transmitting beacons Bitterblue Smith
2024-07-28 22:51 ` [PATCH 2/2] wifi: rtw88: Avoid using macid 0 in AP mode Bitterblue Smith
2024-07-30 6:33 ` Ping-Ke Shih
2024-07-30 12:55 ` Bitterblue Smith
2024-07-31 0:47 ` Ping-Ke Shih
2024-07-31 12:20 ` Bitterblue Smith
2024-08-08 9:38 ` Maciej S. Szmigiero
2024-08-19 2:59 ` Ping-Ke Shih [this message]
2024-08-19 21:20 ` Maciej S. Szmigiero
2024-08-20 0:34 ` Ping-Ke Shih
2024-08-20 23:15 ` Bitterblue Smith
2024-07-31 8:10 ` Ping-Ke Shih
2024-07-30 7:36 ` [PATCH 1/2] wifi: rtw88: Fix USB devices not transmitting beacons Ping-Ke Shih
2024-08-21 6:25 ` Ping-Ke Shih
2024-08-21 7:17 ` Michele Bisogno
2024-08-21 11:17 ` Bitterblue Smith
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=e8d3c81a47de44e1ba7df08b9de826ee@realtek.com \
--to=pkshih@realtek.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=martin.blumenstingl@googlemail.com \
--cc=rtl8821cerfe2@gmail.com \
--cc=sha@pengutronix.de \
/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).