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(-)
--
2.39.2
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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 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 <[email protected]>
> ---
> 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)
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 <[email protected]>
>
> 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 <[email protected]>
>>
>> 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,[email protected]>
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 <[email protected]>
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 <[email protected]>
> > ---
> > 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 |