This series fixes two bugs in the RTW88 USB driver I was reported from several people and that I also encountered myself.
The first one resulted in "timed out to flush queue 3" messages from the driver and sometimes a complete stall of the TX queues.
The second one is specific to the RTW8821CU chipset. Here 2GHz networks were hardly seen and impossible to connect to. This goes down to misinterpreting the rfe_option field in the efuse.
Sascha Hauer (2): wifi: rtw88: usb: fix priority queue to endpoint mapping wifi: rtw88: rtw8821c: Fix rfe_option field width
drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +- drivers/net/wireless/realtek/rtw88/usb.c | 70 +++++++++++++------ 2 files changed, 48 insertions(+), 25 deletions(-)
The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated.
This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver.
Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely.
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de --- drivers/net/wireless/realtek/rtw88/usb.c | 70 ++++++++++++++++-------- 1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c index 2a8336b1847a5..a10d6fef4ffaf 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -118,6 +118,22 @@ static void rtw_usb_write32(struct rtw_dev *rtwdev, u32 addr, u32 val) rtw_usb_write(rtwdev, addr, val, 4); }
+static int dma_mapping_to_ep(enum rtw_dma_mapping dma_mapping) +{ + switch (dma_mapping) { + case RTW_DMA_MAPPING_HIGH: + return 0; + case RTW_DMA_MAPPING_NORMAL: + return 1; + case RTW_DMA_MAPPING_LOW: + return 2; + case RTW_DMA_MAPPING_EXTRA: + return 3; + default: + return -EINVAL; + } +} + static int rtw_usb_parse(struct rtw_dev *rtwdev, struct usb_interface *interface) { @@ -129,6 +145,8 @@ static int rtw_usb_parse(struct rtw_dev *rtwdev, int num_out_pipes = 0; int i; u8 num; + const struct rtw_chip_info *chip = rtwdev->chip; + const struct rtw_rqpn *rqpn;
for (i = 0; i < interface_desc->bNumEndpoints; i++) { endpoint = &host_interface->endpoint[i].desc; @@ -183,31 +201,34 @@ static int rtw_usb_parse(struct rtw_dev *rtwdev,
rtwdev->hci.bulkout_num = num_out_pipes;
- switch (num_out_pipes) { - case 4: - case 3: - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID0] = 2; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID1] = 2; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID2] = 2; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID3] = 2; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID4] = 1; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID5] = 1; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID6] = 0; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID7] = 0; - break; - case 2: - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID0] = 1; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID1] = 1; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID2] = 1; - rtwusb->qsel_to_ep[TX_DESC_QSEL_TID3] = 1; - break; - case 1: - break; - default: - rtw_err(rtwdev, "failed to get out_pipes(%d)\n", num_out_pipes); + if (num_out_pipes < 1 || num_out_pipes > 4) { + rtw_err(rtwdev, "invalid number of endpoints %d\n", num_out_pipes); return -EINVAL; }
+ rqpn = &chip->rqpn_table[num_out_pipes]; + + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID0] = dma_mapping_to_ep(rqpn->dma_map_be); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID1] = dma_mapping_to_ep(rqpn->dma_map_bk); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID2] = dma_mapping_to_ep(rqpn->dma_map_bk); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID3] = dma_mapping_to_ep(rqpn->dma_map_be); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID4] = dma_mapping_to_ep(rqpn->dma_map_vi); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID5] = dma_mapping_to_ep(rqpn->dma_map_vi); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID6] = dma_mapping_to_ep(rqpn->dma_map_vo); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID7] = dma_mapping_to_ep(rqpn->dma_map_vo); + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID8] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID9] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID10] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID11] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID12] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID13] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID14] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_TID15] = -EINVAL; + rtwusb->qsel_to_ep[TX_DESC_QSEL_BEACON] = dma_mapping_to_ep(rqpn->dma_map_hi); + rtwusb->qsel_to_ep[TX_DESC_QSEL_HIGH] = dma_mapping_to_ep(rqpn->dma_map_hi); + rtwusb->qsel_to_ep[TX_DESC_QSEL_MGMT] = dma_mapping_to_ep(rqpn->dma_map_mg); + rtwusb->qsel_to_ep[TX_DESC_QSEL_H2C] = dma_mapping_to_ep(rqpn->dma_map_hi); + return 0; }
@@ -250,7 +271,7 @@ static void rtw_usb_write_port_tx_complete(struct urb *urb) static int qsel_to_ep(struct rtw_usb *rtwusb, unsigned int qsel) { if (qsel >= ARRAY_SIZE(rtwusb->qsel_to_ep)) - return 0; + return -EINVAL;
return rtwusb->qsel_to_ep[qsel]; } @@ -265,6 +286,9 @@ static int rtw_usb_write_port(struct rtw_dev *rtwdev, u8 qsel, struct sk_buff *s int ret; int ep = qsel_to_ep(rtwusb, qsel);
+ if (ep < 0) + return ep; + pipe = usb_sndbulkpipe(usbd, rtwusb->out_ep[ep]); urb = usb_alloc_urb(0, GFP_ATOMIC); if (!urb)
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
Rule: 'Cc: stable@vger.kernel.org' or 'commit <sha1> upstream.' Subject: [PATCH 1/2] wifi: rtw88: usb: fix priority queue to endpoint mapping Link: https://lore.kernel.org/stable/20230331121054.112758-2-s.hauer%40pengutronix...
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
On 3/31/23 08:10, Sascha Hauer wrote:
The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated.
This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver.
Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely.
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de
drivers/net/wireless/realtek/rtw88/usb.c | 70 ++++++++++++++++-------- 1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c index 2a8336b1847a5..a10d6fef4ffaf 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -118,6 +118,22 @@ static void rtw_usb_write32(struct rtw_dev *rtwdev, u32 addr, u32 val) rtw_usb_write(rtwdev, addr, val, 4); } +static int dma_mapping_to_ep(enum rtw_dma_mapping dma_mapping) +{
- switch (dma_mapping) {
- case RTW_DMA_MAPPING_HIGH:
return 0;- case RTW_DMA_MAPPING_NORMAL:
return 1;- case RTW_DMA_MAPPING_LOW:
return 2;- case RTW_DMA_MAPPING_EXTRA:
return 3;- default:
return -EINVAL;- }
+}
Would it be beneficial to use defines for the returns? Would the USB_ENDPOINT_XFER_ defines be applicable?
- static int rtw_usb_parse(struct rtw_dev *rtwdev, struct usb_interface *interface) {
@@ -129,6 +145,8 @@ static int rtw_usb_parse(struct rtw_dev *rtwdev, int num_out_pipes = 0; int i; u8 num;
- const struct rtw_chip_info *chip = rtwdev->chip;
- const struct rtw_rqpn *rqpn;
for (i = 0; i < interface_desc->bNumEndpoints; i++) { endpoint = &host_interface->endpoint[i].desc; @@ -183,31 +201,34 @@ static int rtw_usb_parse(struct rtw_dev *rtwdev, rtwdev->hci.bulkout_num = num_out_pipes;
- switch (num_out_pipes) {
- case 4:
- case 3:
rtwusb->qsel_to_ep[TX_DESC_QSEL_TID0] = 2;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID1] = 2;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID2] = 2;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID3] = 2;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID4] = 1;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID5] = 1;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID6] = 0;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID7] = 0;break;- case 2:
rtwusb->qsel_to_ep[TX_DESC_QSEL_TID0] = 1;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID1] = 1;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID2] = 1;rtwusb->qsel_to_ep[TX_DESC_QSEL_TID3] = 1;break;- case 1:
break;- default:
rtw_err(rtwdev, "failed to get out_pipes(%d)\n", num_out_pipes);
- if (num_out_pipes < 1 || num_out_pipes > 4) {
rtw_err(rtwdev, "invalid number of endpoints %d\n", num_out_pipes);
- rqpn = &chip->rqpn_table[num_out_pipes];
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID0] = dma_mapping_to_ep(rqpn->dma_map_be);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID1] = dma_mapping_to_ep(rqpn->dma_map_bk);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID2] = dma_mapping_to_ep(rqpn->dma_map_bk);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID3] = dma_mapping_to_ep(rqpn->dma_map_be);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID4] = dma_mapping_to_ep(rqpn->dma_map_vi);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID5] = dma_mapping_to_ep(rqpn->dma_map_vi);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID6] = dma_mapping_to_ep(rqpn->dma_map_vo);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID7] = dma_mapping_to_ep(rqpn->dma_map_vo);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID8] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID9] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID10] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID11] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID12] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID13] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID14] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_TID15] = -EINVAL;
- rtwusb->qsel_to_ep[TX_DESC_QSEL_BEACON] = dma_mapping_to_ep(rqpn->dma_map_hi);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_HIGH] = dma_mapping_to_ep(rqpn->dma_map_hi);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_MGMT] = dma_mapping_to_ep(rqpn->dma_map_mg);
- rtwusb->qsel_to_ep[TX_DESC_QSEL_H2C] = dma_mapping_to_ep(rqpn->dma_map_hi);
- return 0; }
@@ -250,7 +271,7 @@ static void rtw_usb_write_port_tx_complete(struct urb *urb) static int qsel_to_ep(struct rtw_usb *rtwusb, unsigned int qsel) { if (qsel >= ARRAY_SIZE(rtwusb->qsel_to_ep))
return 0;
return -EINVAL;return rtwusb->qsel_to_ep[qsel]; } @@ -265,6 +286,9 @@ static int rtw_usb_write_port(struct rtw_dev *rtwdev, u8 qsel, struct sk_buff *s int ret; int ep = qsel_to_ep(rtwusb, qsel);
- if (ep < 0)
return ep;- pipe = usb_sndbulkpipe(usbd, rtwusb->out_ep[ep]); urb = usb_alloc_urb(0, GFP_ATOMIC); if (!urb)
On Fri, Mar 31, 2023 at 10:31:25AM -0400, Jonathan Bither wrote:
On 3/31/23 08:10, Sascha Hauer wrote:
The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated.
This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver.
Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely.
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de
drivers/net/wireless/realtek/rtw88/usb.c | 70 ++++++++++++++++-------- 1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c index 2a8336b1847a5..a10d6fef4ffaf 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -118,6 +118,22 @@ static void rtw_usb_write32(struct rtw_dev *rtwdev, u32 addr, u32 val) rtw_usb_write(rtwdev, addr, val, 4); } +static int dma_mapping_to_ep(enum rtw_dma_mapping dma_mapping) +{
- switch (dma_mapping) {
- case RTW_DMA_MAPPING_HIGH:
return 0;- case RTW_DMA_MAPPING_NORMAL:
return 1;- case RTW_DMA_MAPPING_LOW:
return 2;- case RTW_DMA_MAPPING_EXTRA:
return 3;- default:
return -EINVAL;- }
+}
Would it be beneficial to use defines for the returns? Would the USB_ENDPOINT_XFER_ defines be applicable?
The USB_ENDPOINT_XFER_* macros encode the type of the transfer, like bulk, control, isochronous and interrupt. What I need here really is the endpoint number. I don't see a benefit in adding a define here.
Sascha
On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the downstream driver suggests that the field width of rfe_option is 5 bit, so rfe_option should be masked with 0x1f.
Without this the rfe_option comparisons with 2 further down the driver evaluate as false when they should really evaluate as true. The effect is that 2G channels do not work.
rfe_option is also used as an array index into rtw8821c_rfe_defs[]. rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support, likely because rfe_option reads as 0x22. As this now becomes 0x2, rtw8821c_rfe_defs[34] is no longer used and can be removed.
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de --- drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wireless/realtek/rtw88/rtw8821c.c index 17f800f6efbd0..67efa58dd78ee 100644 --- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c +++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c @@ -47,7 +47,7 @@ static int rtw8821c_read_efuse(struct rtw_dev *rtwdev, u8 *log_map)
map = (struct rtw8821c_efuse *)log_map;
- efuse->rfe_option = map->rfe_option; + efuse->rfe_option = map->rfe_option & 0x1f; efuse->rf_board_option = map->rf_board_option; efuse->crystal_cap = map->xtal_k; efuse->pa_type_2g = map->pa_type; @@ -1537,7 +1537,6 @@ static const struct rtw_rfe_def rtw8821c_rfe_defs[] = { [2] = RTW_DEF_RFE_EXT(8821c, 0, 0, 2), [4] = RTW_DEF_RFE_EXT(8821c, 0, 0, 2), [6] = RTW_DEF_RFE(8821c, 0, 0), - [34] = RTW_DEF_RFE(8821c, 0, 0), };
static struct rtw_hw_reg rtw8821c_dig[] = {
On Fri, Mar 31, 2023 at 02:10:54PM +0200, Sascha Hauer wrote:
On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the downstream driver suggests that the field width of rfe_option is 5 bit, so rfe_option should be masked with 0x1f.
Without this the rfe_option comparisons with 2 further down the driver evaluate as false when they should really evaluate as true. The effect is that 2G channels do not work.
rfe_option is also used as an array index into rtw8821c_rfe_defs[]. rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support, likely because rfe_option reads as 0x22. As this now becomes 0x2, rtw8821c_rfe_defs[34] is no longer used and can be removed.
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de
drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
On 3/31/23 07:10, Sascha Hauer wrote:
This series fixes two bugs in the RTW88 USB driver I was reported from several people and that I also encountered myself.
The first one resulted in "timed out to flush queue 3" messages from the driver and sometimes a complete stall of the TX queues.
The second one is specific to the RTW8821CU chipset. Here 2GHz networks were hardly seen and impossible to connect to. This goes down to misinterpreting the rfe_option field in the efuse.
I applied both these patches, tested an 8821CU, and the news are good:
The number of kernel warnings and adapter hangs has gone down considerably.
The signal levels on 2.4GHz bands have improved noticeably. There is the occasional station coming in 30dB lower than on nearby adapters. I wasn't able to find a pattern here.
I can now run these adapters in IBSS and 802.11s modes on the 2.4 GHz band. That was not possible before.
I am impressed with the improvements in these patches. For the series:
Tested-by: Alexandru gagniuc mr.nuke.me@gmail.com
Sascha Hauer (2): wifi: rtw88: usb: fix priority queue to endpoint mapping wifi: rtw88: rtw8821c: Fix rfe_option field width
drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +- drivers/net/wireless/realtek/rtw88/usb.c | 70 +++++++++++++------ 2 files changed, 48 insertions(+), 25 deletions(-)
On 3/31/23 15:34, Alex G. wrote:
On 3/31/23 07:10, Sascha Hauer wrote:
This series fixes two bugs in the RTW88 USB driver I was reported from several people and that I also encountered myself.
The first one resulted in "timed out to flush queue 3" messages from the driver and sometimes a complete stall of the TX queues.
The second one is specific to the RTW8821CU chipset. Here 2GHz networks were hardly seen and impossible to connect to. This goes down to misinterpreting the rfe_option field in the efuse.
I applied both these patches, tested an 8821CU, and the news are good:
The number of kernel warnings and adapter hangs has gone down considerably.
The signal levels on 2.4GHz bands have improved noticeably. There is the occasional station coming in 30dB lower than on nearby adapters. I wasn't able to find a pattern here.
I can now run these adapters in IBSS and 802.11s modes on the 2.4 GHz band. That was not possible before.
I am impressed with the improvements in these patches. For the series:
Tested-by: Alexandru gagniuc mr.nuke.me@gmail.com
Sascha Hauer (2): wifi: rtw88: usb: fix priority queue to endpoint mapping wifi: rtw88: rtw8821c: Fix rfe_option field width
drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +- >> drivers/net/wireless/realtek/rtw88/usb.c | 70 +++++++++++++------ 2 files changed, 48 insertions(+), 25 deletions(-)
I can confirm that these changes cleared up my problems with the "timed out to flush queue" warnings that caused a problem before with my rtw8822bu.
Tested-by: Larry Finger <Larry,Finger@lwfinger.net>
Thanks,
Larry
On 31.03.2023 23:34, Alex G. wrote:
On 3/31/23 07:10, Sascha Hauer wrote:
This series fixes two bugs in the RTW88 USB driver I was reported from several people and that I also encountered myself.
The first one resulted in "timed out to flush queue 3" messages from the driver and sometimes a complete stall of the TX queues.
The second one is specific to the RTW8821CU chipset. Here 2GHz networks were hardly seen and impossible to connect to. This goes down to misinterpreting the rfe_option field in the efuse.
Tested on RTL8811CU, these two patches fix both issues. 2.4 GHz networks now work perfectly fine.
Tested-by: ValdikSS iam@valdikss.org.ru
linux-stable-mirror@lists.linaro.org
-
Alex G. -
Greg KH -
Jonathan Bither -
kernel test robot -
Larry Finger -
Sascha Hauer -
ValdikSS