This series adds support for the USB chip variants to the RTW88 driver.

The first patches in the series consolidate the locking in the driver.
The rtw88 driver protects the register accesses with spinlocks which
naturally don't cope well with the asynchronous nature of USB. It turned
out though that in most cases where additional locks are taken the
global driver mutex is acquired anyway which makes them mostly
unnecessary. The exception is the debugfs code which depends on the
additional locks. This is changed to acquire the global driver mutex as
well, so the additional locks can be removed.  I verified the callstacks
leading to the different locks with a cscope based shell script, so I am
pretty confident that I haven't missed any pathes. Nevertheless please
have a careful look, please.

Another problem to address is that the driver uses
ieee80211_iterate_stations_atomic() and
ieee80211_iterate_active_interfaces_atomic() and does register accesses
in the iterator. This doesn't work with USB, so iteration is done in two
steps now: The ieee80211_iterate_*_atomic() functions are only used to
collect the stations/interfaces on a list which is then iterated over
non-atomically in the second step. The implementation for this is
basically the one suggested by Ping-Ke here:
https://lore.kernel.org/lkml/423f474e15c948eda4db5bc9a50fd391@realtek.com/

The USB driver code itself is based on
https://github.com/ulli-kroll/rtw88-usb.git.  The most significant
change to that code base is likely the TX queue handling.  It seems the
PCI versions of the RTW88 chips have eight differently prioritized TX
queues whereas the USB variants only have one to three queues (one per
bulk endpoint).  The original code base first mapped the TX packets
coming into the driver onto eight TX queues which were then re-mapped
again to the existing endpoints. As the eight TX queues do not
physically exist on the USB variants I changed that to map the incoming
TX packets directly onto the bulk endpoints.

I tested this series on the RTW8822CU only. I don't have access to any
of the other chips supported by the RTW88 driver, so testing feedback
would be greatly appreciated.

This is my first excursion to the Linux wireless world, so please review
carefully :)

Sascha


Sascha Hauer (10):
  rtw88: Call rtw_fw_beacon_filter_config() with rtwdev->mutex held
  rtw88: Drop rf_lock
  rtw88: Drop h2c.lock
  rtw88: Drop coex mutex
  rtw88: Do not access registers while atomic
  rtw88: Add common USB chip support
  rtw88: Add rtw8723du chipset support
  rtw88: Add rtw8821cu chipset support
  rtw88: Add rtw8822bu chipset support
  rtw88: Add rtw8822cu chipset support

 drivers/net/wireless/realtek/rtw88/Kconfig    |   47 +
 drivers/net/wireless/realtek/rtw88/Makefile   |   14 +
 drivers/net/wireless/realtek/rtw88/coex.c     |    3 +-
 drivers/net/wireless/realtek/rtw88/debug.c    |   15 +
 drivers/net/wireless/realtek/rtw88/fw.c       |   13 +-
 drivers/net/wireless/realtek/rtw88/hci.h      |    9 +-
 drivers/net/wireless/realtek/rtw88/mac.c      |    3 +
 drivers/net/wireless/realtek/rtw88/mac80211.c |    2 +-
 drivers/net/wireless/realtek/rtw88/main.c     |    9 +-
 drivers/net/wireless/realtek/rtw88/main.h     |   11 +-
 drivers/net/wireless/realtek/rtw88/phy.c      |    6 +-
 drivers/net/wireless/realtek/rtw88/ps.c       |    2 +-
 drivers/net/wireless/realtek/rtw88/reg.h      |    1 +
 drivers/net/wireless/realtek/rtw88/rtw8723d.c |   19 +
 drivers/net/wireless/realtek/rtw88/rtw8723d.h |    1 +
 .../net/wireless/realtek/rtw88/rtw8723du.c    |   40 +
 .../net/wireless/realtek/rtw88/rtw8723du.h    |   13 +
 drivers/net/wireless/realtek/rtw88/rtw8821c.c |   23 +
 drivers/net/wireless/realtek/rtw88/rtw8821c.h |   21 +
 .../net/wireless/realtek/rtw88/rtw8821cu.c    |   69 ++
 .../net/wireless/realtek/rtw88/rtw8821cu.h    |   15 +
 drivers/net/wireless/realtek/rtw88/rtw8822b.c |   19 +
 .../net/wireless/realtek/rtw88/rtw8822bu.c    |   62 +
 .../net/wireless/realtek/rtw88/rtw8822bu.h    |   15 +
 drivers/net/wireless/realtek/rtw88/rtw8822c.c |   24 +
 .../net/wireless/realtek/rtw88/rtw8822cu.c    |   40 +
 .../net/wireless/realtek/rtw88/rtw8822cu.h    |   15 +
 drivers/net/wireless/realtek/rtw88/tx.h       |   31 +
 drivers/net/wireless/realtek/rtw88/usb.c      | 1051 +++++++++++++++++
 drivers/net/wireless/realtek/rtw88/usb.h      |  109 ++
 drivers/net/wireless/realtek/rtw88/util.c     |   92 ++
 drivers/net/wireless/realtek/rtw88/util.h     |   12 +-
 32 files changed, 1770 insertions(+), 36 deletions(-)
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8723du.c
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8723du.h
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8821cu.c
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8821cu.h
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822bu.c
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822bu.h
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822cu.c
 create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822cu.h
 create mode 100644 drivers/net/wireless/realtek/rtw88/usb.c
 create mode 100644 drivers/net/wireless/realtek/rtw88/usb.h

-- 
2.30.2

Sascha Hauer <s.hauer@pengutronix.de> writes:

> Another problem to address is that the driver uses
> ieee80211_iterate_stations_atomic() and
> ieee80211_iterate_active_interfaces_atomic() and does register accesses
> in the iterator. This doesn't work with USB, so iteration is done in two
> steps now: The ieee80211_iterate_*_atomic() functions are only used to
> collect the stations/interfaces on a list which is then iterated over
> non-atomically in the second step. The implementation for this is
> basically the one suggested by Ping-Ke here:
>
> https://lore.kernel.org/lkml/423f474e15c948eda4db5bc9a50fd391@realtek.com/

Isn't this racy? What guarantees that vifs are not deleted after
ieee80211_iterate_active_interfaces_atomic() call?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

On Mon, May 30, 2022 at 12:25:13PM +0300, Kalle Valo wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > Another problem to address is that the driver uses
> > ieee80211_iterate_stations_atomic() and
> > ieee80211_iterate_active_interfaces_atomic() and does register accesses
> > in the iterator. This doesn't work with USB, so iteration is done in two
> > steps now: The ieee80211_iterate_*_atomic() functions are only used to
> > collect the stations/interfaces on a list which is then iterated over
> > non-atomically in the second step. The implementation for this is
> > basically the one suggested by Ping-Ke here:
> >
> > https://lore.kernel.org/lkml/423f474e15c948eda4db5bc9a50fd391@realtek.com/
> 
> Isn't this racy? What guarantees that vifs are not deleted after
> ieee80211_iterate_active_interfaces_atomic() call?

The driver mutex &rtwdev->mutex is acquired during the whole
collection/iteration process. For deleting an interface
ieee80211_ops::remove_interface would have to be called, right?
That would acquire &rtwdev->mutex as well, so I think this should be
safe.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Mon, May 30, 2022 at 12:25:13PM +0300, Kalle Valo wrote:
>> Sascha Hauer <s.hauer@pengutronix.de> writes:
>> 
>> > Another problem to address is that the driver uses
>> > ieee80211_iterate_stations_atomic() and
>> > ieee80211_iterate_active_interfaces_atomic() and does register accesses
>> > in the iterator. This doesn't work with USB, so iteration is done in two
>> > steps now: The ieee80211_iterate_*_atomic() functions are only used to
>> > collect the stations/interfaces on a list which is then iterated over
>> > non-atomically in the second step. The implementation for this is
>> > basically the one suggested by Ping-Ke here:
>> >
>> > https://lore.kernel.org/lkml/423f474e15c948eda4db5bc9a50fd391@realtek.com/
>> 
>> Isn't this racy? What guarantees that vifs are not deleted after
>> ieee80211_iterate_active_interfaces_atomic() call?
>
> The driver mutex &rtwdev->mutex is acquired during the whole
> collection/iteration process. For deleting an interface
> ieee80211_ops::remove_interface would have to be called, right?
> That would acquire &rtwdev->mutex as well, so I think this should be
> safe.

Can you add a comment to the code explaining this? And
lockdep_assert_held() is a good way to guarantee that the mutex is
really held.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

On Mon, May 30, 2022 at 01:07:25PM +0300, Kalle Valo wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > On Mon, May 30, 2022 at 12:25:13PM +0300, Kalle Valo wrote:
> >> Sascha Hauer <s.hauer@pengutronix.de> writes:
> >> 
> >> > Another problem to address is that the driver uses
> >> > ieee80211_iterate_stations_atomic() and
> >> > ieee80211_iterate_active_interfaces_atomic() and does register accesses
> >> > in the iterator. This doesn't work with USB, so iteration is done in two
> >> > steps now: The ieee80211_iterate_*_atomic() functions are only used to
> >> > collect the stations/interfaces on a list which is then iterated over
> >> > non-atomically in the second step. The implementation for this is
> >> > basically the one suggested by Ping-Ke here:
> >> >
> >> > https://lore.kernel.org/lkml/423f474e15c948eda4db5bc9a50fd391@realtek.com/
> >> 
> >> Isn't this racy? What guarantees that vifs are not deleted after
> >> ieee80211_iterate_active_interfaces_atomic() call?
> >
> > The driver mutex &rtwdev->mutex is acquired during the whole
> > collection/iteration process. For deleting an interface
> > ieee80211_ops::remove_interface would have to be called, right?
> > That would acquire &rtwdev->mutex as well, so I think this should be
> > safe.
> 
> Can you add a comment to the code explaining this?

Sure.

> And
> lockdep_assert_held() is a good way to guarantee that the mutex is
> really held.

Yes, Ping-Ke already pointed that out. Will add in the next round.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

On Wed, 2022-05-18 at 10:23 +0200, Sascha Hauer wrote:
> This series adds support for the USB chip variants to the RTW88 driver.
> 

Hi Sascha

glad you found some *working* devices for rtw88 !

I spend some of the weekend testing your driver submission.

for rtl8821cu devices I get following output

some Logilink device

[ 1686.605567] usb 1-5.1.2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice=
2.00
[ 1686.614186] usb 1-5.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1686.621721] usb 1-5.1.2: Product: 802.11ac NIC
[ 1686.626227] usb 1-5.1.2: Manufacturer: Realtek
[ 1686.630695] usb 1-5.1.2: SerialNumber: 123456
[ 1686.640480] rtw_8821cu 1-5.1.2:1.0: Firmware version 24.5.0, H2C version 12
[ 1686.932828] rtw_8821cu 1-5.1.2:1.0: failed to download firmware
[ 1686.945206] rtw_8821cu 1-5.1.2:1.0: failed to setup chip efuse info
[ 1686.951538] rtw_8821cu 1-5.1.2:1.0: failed to setup chip information
[ 1686.958402] rtw_8821cu: probe of 1-5.1.2:1.0 failed with error -22

above is same with some from Comfast

The worst in the list is one from EDUP

[ 1817.855704] rtw_8821cu 1-5.1.2:1.2: Firmware version 24.5.0, H2C version 12
[ 1818.153918] rtw_8821cu 1-5.1.2:1.2: rfe 255 isn't supported
[ 1818.165176] rtw_8821cu 1-5.1.2:1.2: failed to setup chip efuse info
[ 1818.171505] rtw_8821cu 1-5.1.2:1.2: failed to setup chip information

rtl8822bu devices are working fine ...

Hans Ulli

On Mon, May 23, 2022 at 06:07:16AM +0200, Hans Ulli Kroll wrote:
> On Wed, 2022-05-18 at 10:23 +0200, Sascha Hauer wrote:
> > This series adds support for the USB chip variants to the RTW88 driver.
> > 
> 
> Hi Sascha
> 
> glad you found some *working* devices for rtw88 !
> 
> I spend some of the weekend testing your driver submission.
> 
> for rtl8821cu devices I get following output
> 
> some Logilink device
> 
> [ 1686.605567] usb 1-5.1.2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice=
> 2.00

Most devices in the driver are described as:

	USB_DEVICE_AND_INTERFACE_INFO(0x0bda, 0xc82c, 0xff, 0xff, 0xff),

This particular one has:

	USB_DEVICE(0x0bda, 0xc811),

When I use USB_DEVICE() instead of USB_DEVICE_AND_INTERFACE_INFO() on my
device then the Wifi driver tries to bind to the bluetooth interface on
the same device which then fails with similar error messages. Maybe you
have to use

	USB_DEVICE_AND_INTERFACE_INFO(0x0bda, 0xc811, 0xff, 0xff, 0xff)

instead. I could imagine that the plain USB_DEVICE() once worked for you
because the bluetooth driver was faster to probe and only left the Wifi
interface free for the Wifi driver to probe.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Hi Hans Ulli,

On Mon, May 23, 2022 at 06:07:16AM +0200, Hans Ulli Kroll wrote:
> On Wed, 2022-05-18 at 10:23 +0200, Sascha Hauer wrote:
> > This series adds support for the USB chip variants to the RTW88 driver.
> > 
> 
> Hi Sascha
> 
> glad you found some *working* devices for rtw88 !

Well, not fully. I had to add [3] = RTW_DEF_RFE(8822c, 0, 0), to the
rtw8822c_rfe_defs array.

> 
> I spend some of the weekend testing your driver submission.
> 
> for rtl8821cu devices I get following output
> 
> some Logilink device
> 
> [ 1686.605567] usb 1-5.1.2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice=
> 2.00
> [ 1686.614186] usb 1-5.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 1686.621721] usb 1-5.1.2: Product: 802.11ac NIC
> [ 1686.626227] usb 1-5.1.2: Manufacturer: Realtek
> [ 1686.630695] usb 1-5.1.2: SerialNumber: 123456
> [ 1686.640480] rtw_8821cu 1-5.1.2:1.0: Firmware version 24.5.0, H2C version 12
> [ 1686.932828] rtw_8821cu 1-5.1.2:1.0: failed to download firmware
> [ 1686.945206] rtw_8821cu 1-5.1.2:1.0: failed to setup chip efuse info
> [ 1686.951538] rtw_8821cu 1-5.1.2:1.0: failed to setup chip information
> [ 1686.958402] rtw_8821cu: probe of 1-5.1.2:1.0 failed with error -22
> 
> above is same with some from Comfast
> 
> The worst in the list is one from EDUP
> 
> [ 1817.855704] rtw_8821cu 1-5.1.2:1.2: Firmware version 24.5.0, H2C version 12
> [ 1818.153918] rtw_8821cu 1-5.1.2:1.2: rfe 255 isn't supported
> [ 1818.165176] rtw_8821cu 1-5.1.2:1.2: failed to setup chip efuse info
> [ 1818.171505] rtw_8821cu 1-5.1.2:1.2: failed to setup chip information

Do these chips work with your out of tree variant of this driver?

Is the efuse info completely 0xff or only the field indicating the rfe
option?

> 
> rtl8822bu devices are working fine ...

Nice. Did you test a rtw8723du device as well?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

On Mon, 2022-05-23 at 08:53 +0200, Sascha Hauer wrote:
> Hi Hans Ulli,
> 
> On Mon, May 23, 2022 at 06:07:16AM +0200, Hans Ulli Kroll wrote:
> > On Wed, 2022-05-18 at 10:23 +0200, Sascha Hauer wrote:
> > > This series adds support for the USB chip variants to the RTW88 driver.
> > > 
> > 
> > Hi Sascha
> > 
> > glad you found some *working* devices for rtw88 !
> 
> Well, not fully. I had to add [3] = RTW_DEF_RFE(8822c, 0, 0), to the
> rtw8822c_rfe_defs array.
> 
> > I spend some of the weekend testing your driver submission.
> > 
> > for rtl8821cu devices I get following output
> > 
> > some Logilink device
> > 
> > [ 1686.605567] usb 1-5.1.2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice=
> > 2.00
> > [ 1686.614186] usb 1-5.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > [ 1686.621721] usb 1-5.1.2: Product: 802.11ac NIC
> > [ 1686.626227] usb 1-5.1.2: Manufacturer: Realtek
> > [ 1686.630695] usb 1-5.1.2: SerialNumber: 123456
> > [ 1686.640480] rtw_8821cu 1-5.1.2:1.0: Firmware version 24.5.0, H2C version 12
> > [ 1686.932828] rtw_8821cu 1-5.1.2:1.0: failed to download firmware
> > [ 1686.945206] rtw_8821cu 1-5.1.2:1.0: failed to setup chip efuse info
> > [ 1686.951538] rtw_8821cu 1-5.1.2:1.0: failed to setup chip information
> > [ 1686.958402] rtw_8821cu: probe of 1-5.1.2:1.0 failed with error -22
> > 
> > above is same with some from Comfast
> > 
> > The worst in the list is one from EDUP
> > 
> > [ 1817.855704] rtw_8821cu 1-5.1.2:1.2: Firmware version 24.5.0, H2C version 12
> > [ 1818.153918] rtw_8821cu 1-5.1.2:1.2: rfe 255 isn't supported
> > [ 1818.165176] rtw_8821cu 1-5.1.2:1.2: failed to setup chip efuse info
> > [ 1818.171505] rtw_8821cu 1-5.1.2:1.2: failed to setup chip information
> 
> Do these chips work with your out of tree variant of this driver?
> 
> Is the efuse info completely 0xff or only the field indicating the rfe
> option?

I check RFE allocation of 8821c. 255 isn't defined.
If efuse info isn't complete 0xff, try to force RFE 0 to see if it works.

> 
> > rtl8822bu devices are working fine ...
> 
> Nice. Did you test a rtw8723du device as well?
> 

I have a 8723DU module.

With this patchset, it can find AP, but can't estiablish connection.
I check air capture, but no TX packets found.
That says RX works, but TX doesn't.

With master branch of Hans Ulli GitHub, it shows many "atomic scheduling"
warnings when I insert the USB dongle.
When I do 'iw scan', it is going to get stuck, and I can only push
power button to turn off my laptop.

Ping-Ke

On Mon, May 23, 2022 at 11:39:49AM +0000, Ping-Ke Shih wrote:
> On Mon, 2022-05-23 at 08:53 +0200, Sascha Hauer wrote:
> > Hi Hans Ulli,
> > 
> > On Mon, May 23, 2022 at 06:07:16AM +0200, Hans Ulli Kroll wrote:
> > > On Wed, 2022-05-18 at 10:23 +0200, Sascha Hauer wrote:
> > > > This series adds support for the USB chip variants to the RTW88 driver.
> > > > 
> > > 
> > > Hi Sascha
> > > 
> > > glad you found some *working* devices for rtw88 !
> > 
> > Well, not fully. I had to add [3] = RTW_DEF_RFE(8822c, 0, 0), to the
> > rtw8822c_rfe_defs array.
> > 
> > > I spend some of the weekend testing your driver submission.
> > > 
> > > for rtl8821cu devices I get following output
> > > 
> > > some Logilink device
> > > 
> > > [ 1686.605567] usb 1-5.1.2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice=
> > > 2.00
> > > [ 1686.614186] usb 1-5.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > > [ 1686.621721] usb 1-5.1.2: Product: 802.11ac NIC
> > > [ 1686.626227] usb 1-5.1.2: Manufacturer: Realtek
> > > [ 1686.630695] usb 1-5.1.2: SerialNumber: 123456
> > > [ 1686.640480] rtw_8821cu 1-5.1.2:1.0: Firmware version 24.5.0, H2C version 12
> > > [ 1686.932828] rtw_8821cu 1-5.1.2:1.0: failed to download firmware
> > > [ 1686.945206] rtw_8821cu 1-5.1.2:1.0: failed to setup chip efuse info
> > > [ 1686.951538] rtw_8821cu 1-5.1.2:1.0: failed to setup chip information
> > > [ 1686.958402] rtw_8821cu: probe of 1-5.1.2:1.0 failed with error -22
> > > 
> > > above is same with some from Comfast
> > > 
> > > The worst in the list is one from EDUP
> > > 
> > > [ 1817.855704] rtw_8821cu 1-5.1.2:1.2: Firmware version 24.5.0, H2C version 12
> > > [ 1818.153918] rtw_8821cu 1-5.1.2:1.2: rfe 255 isn't supported
> > > [ 1818.165176] rtw_8821cu 1-5.1.2:1.2: failed to setup chip efuse info
> > > [ 1818.171505] rtw_8821cu 1-5.1.2:1.2: failed to setup chip information
> > 
> > Do these chips work with your out of tree variant of this driver?
> > 
> > Is the efuse info completely 0xff or only the field indicating the rfe
> > option?
> 
> I check RFE allocation of 8821c. 255 isn't defined.
> If efuse info isn't complete 0xff, try to force RFE 0 to see if it works.
> 
> > 
> > > rtl8822bu devices are working fine ...
> > 
> > Nice. Did you test a rtw8723du device as well?
> > 
> 
> I have a 8723DU module.
> 
> With this patchset, it can find AP, but can't estiablish connection.
> I check air capture, but no TX packets found.
> That says RX works, but TX doesn't.

The rtw88 repository has 8723DU support added with:

	initial for RTW8723DU devices

    	not tested, no Device
	Hints are found in rtl8822bu code

No active commits to this file since then, so it's probably not supposed
to work.  Unless somebody comes up with fixes I'll remove support for
this chip for now.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |