| Message ID | 20220518082318.3898514-1-s.hauer@pengutronix.de |
|---|---|
| Headers | show |
| Series | RTW88: Add support for USB variants | expand |
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
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
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
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
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?
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
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.
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