* [PATCH 1/2] wifi: rtw88: usb: fix priority queue to endpoint mapping
2023-03-31 12:10 [PATCH 0/2] RTW88 USB bug fixes Sascha Hauer
@ 2023-03-31 12:10 ` Sascha Hauer
2023-03-31 14:31 ` Jonathan Bither
2023-03-31 12:10 ` [PATCH 2/2] wifi: rtw88: rtw8821c: Fix rfe_option field width Sascha Hauer
2023-03-31 20:34 ` [PATCH 0/2] RTW88 USB bug fixes Alex G.
2 siblings, 1 reply; 9+ messages in thread
From: Sascha Hauer @ 2023-03-31 12:10 UTC (permalink / raw)
To: linux-wireless
Cc: Hans Ulli Kroll, Larry Finger, Pkshih, Tim K, Alex G .,
Nick Morrow, Viktor Petrenko, Andreas Henriksson, ValdikSS,
kernel, stable, Sascha Hauer
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)
--
2.39.2
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH 1/2] wifi: rtw88: usb: fix priority queue to endpoint mapping
2023-03-31 12:10 ` [PATCH 1/2] wifi: rtw88: usb: fix priority queue to endpoint mapping Sascha Hauer
@ 2023-03-31 14:31 ` Jonathan Bither
2023-04-04 7:11 ` Sascha Hauer
0 siblings, 1 reply; 9+ messages in thread
From: Jonathan Bither @ 2023-03-31 14:31 UTC (permalink / raw)
To: Sascha Hauer, linux-wireless
Cc: Hans Ulli Kroll, Larry Finger, Pkshih, Tim K, Alex G .,
Nick Morrow, Viktor Petrenko, Andreas Henriksson, ValdikSS,
kernel, stable
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);
> 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)
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/2] wifi: rtw88: usb: fix priority queue to endpoint mapping
2023-03-31 14:31 ` Jonathan Bither
@ 2023-04-04 7:11 ` Sascha Hauer
0 siblings, 0 replies; 9+ messages in thread
From: Sascha Hauer @ 2023-04-04 7:11 UTC (permalink / raw)
To: Jonathan Bither
Cc: linux-wireless, Hans Ulli Kroll, Larry Finger, Pkshih, Tim K,
Alex G .,
Nick Morrow, Viktor Petrenko, Andreas Henriksson, ValdikSS,
kernel, stable
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
--
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 |
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 2/2] wifi: rtw88: rtw8821c: Fix rfe_option field width
2023-03-31 12:10 [PATCH 0/2] RTW88 USB bug fixes Sascha Hauer
2023-03-31 12:10 ` [PATCH 1/2] wifi: rtw88: usb: fix priority queue to endpoint mapping Sascha Hauer
@ 2023-03-31 12:10 ` Sascha Hauer
2023-03-31 13:16 ` Greg KH
2023-03-31 20:34 ` [PATCH 0/2] RTW88 USB bug fixes Alex G.
2 siblings, 1 reply; 9+ messages in thread
From: Sascha Hauer @ 2023-03-31 12:10 UTC (permalink / raw)
To: linux-wireless
Cc: Hans Ulli Kroll, Larry Finger, Pkshih, Tim K, Alex G .,
Nick Morrow, Viktor Petrenko, Andreas Henriksson, ValdikSS,
kernel, stable, Sascha Hauer
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[] = {
--
2.39.2
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH 2/2] wifi: rtw88: rtw8821c: Fix rfe_option field width
2023-03-31 12:10 ` [PATCH 2/2] wifi: rtw88: rtw8821c: Fix rfe_option field width Sascha Hauer
@ 2023-03-31 13:16 ` Greg KH
0 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2023-03-31 13:16 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-wireless, Hans Ulli Kroll, Larry Finger, Pkshih, Tim K,
Alex G .,
Nick Morrow, Viktor Petrenko, Andreas Henriksson, ValdikSS,
kernel, stable
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>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] RTW88 USB bug fixes
2023-03-31 12:10 [PATCH 0/2] RTW88 USB bug fixes Sascha Hauer
2023-03-31 12:10 ` [PATCH 1/2] wifi: rtw88: usb: fix priority queue to endpoint mapping Sascha Hauer
2023-03-31 12:10 ` [PATCH 2/2] wifi: rtw88: rtw8821c: Fix rfe_option field width Sascha Hauer
@ 2023-03-31 20:34 ` Alex G.
2023-04-01 2:05 ` Larry Finger
2023-04-01 2:08 ` ValdikSS
2 siblings, 2 replies; 9+ messages in thread
From: Alex G. @ 2023-03-31 20:34 UTC (permalink / raw)
To: Sascha Hauer, linux-wireless
Cc: Hans Ulli Kroll, Larry Finger, Pkshih, Tim K, Nick Morrow,
Viktor Petrenko, Andreas Henriksson, ValdikSS, kernel, stable
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(-)
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] RTW88 USB bug fixes
2023-03-31 20:34 ` [PATCH 0/2] RTW88 USB bug fixes Alex G.
@ 2023-04-01 2:05 ` Larry Finger
2023-04-01 2:08 ` ValdikSS
1 sibling, 0 replies; 9+ messages in thread
From: Larry Finger @ 2023-04-01 2:05 UTC (permalink / raw)
To: Alex G., Sascha Hauer, linux-wireless
Cc: Hans Ulli Kroll, Pkshih, Tim K, Nick Morrow, Viktor Petrenko,
Andreas Henriksson, ValdikSS, kernel, stable
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] RTW88 USB bug fixes
2023-03-31 20:34 ` [PATCH 0/2] RTW88 USB bug fixes Alex G.
2023-04-01 2:05 ` Larry Finger
@ 2023-04-01 2:08 ` ValdikSS
1 sibling, 0 replies; 9+ messages in thread
From: ValdikSS @ 2023-04-01 2:08 UTC (permalink / raw)
To: Sascha Hauer, linux-wireless
Cc: Hans Ulli Kroll, Larry Finger, Pkshih, Tim K, Nick Morrow,
Viktor Petrenko, Andreas Henriksson, kernel, stable, Alex G.
[-- Attachment #1.1: Type: text/plain, Size: 701 bytes --]
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>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread