USB: error messages on DWC3 gadget endpoint dequeue
Hi Marek,
I was testing fastboot image download over usb for imx8mp (from usb recovery patch of verdin-imx8mp) and i am having error messages on endpoint request dequeue function of DWC3 gadget controller. However, download is working fine, so this message may not be an error. They are happening because fastboot tx before sending a new usb request dequeue the same request, maybe to be sure it does not send it twice. Can I just ignore these messages? Maybe change its log level to dbg instead of error? What do you think? The messages I am seeing are below and are the ones with "... was not queued to ep1in-bulk".
U-Boot 2023.10-rc3-00028-gc99d052c76 (Sep 14 2023 - 15:59:22 -0300)
CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz) CPU: Industrial temperature grade (-40C to 105C) at 47C Reset cause: POR DRAM: 4 GiB Core: 168 devices, 28 uclasses, devicetree: separate WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK In: serial@30880000 Out: serial@30880000 Err: serial@30880000 Model: Toradex 0058 Verdin iMX8M Plus Quad 4GB WB IT V1.1A Serial#: 15007098 Carrier: Toradex Dahlia V1.1C, Serial# 10952631 SEC0: RNG instantiated Net: eth1: ethernet@30be0000, eth0: ethernet@30bf0000 [PRIME] Hit any key to stop autoboot: 0 Verdin iMX8MP # Verdin iMX8MP # fastboot 0 dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk Starting download of 3084 bytes dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk
downloading of 3084 bytes finished dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk Starting download of 86 bytes dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk
downloading of 86 bytes finished dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk Starting download of 47173400 bytes dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk ....................................................................... ... ....................................................................... ... ....................................................................... ... ....................................................................... ... ............................................................... downloading of 47173400 bytes finished dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk dwc3-generic-peripheral usb@38100000: request 00000000ffb29c40 was not queued to ep1in-bulk
Thanks, Joao Paulo
On 15/09/2023 15.05, João Paulo Silva Gonçalves wrote:
Hi Marek,
I was testing fastboot image download over usb for imx8mp (from usb recovery patch of verdin-imx8mp) and i am having error messages on endpoint request dequeue function of DWC3 gadget controller. However, download is working fine, so this message may not be an error. They are happening because fastboot tx before sending a new usb request dequeue the same request, maybe to be sure it does not send it twice. Can I just ignore these messages? Maybe change its log level to dbg instead of error? What do you think? The messages I am seeing are below and are the ones with "... was not queued to ep1in-bulk".
We apply this internally (sorry if it's whitespace damaged), but I never fully understood the problem nor how the referenced kernel thread was resolved, which is why I haven't sent it upstream yet.
dwc3: gadget: Handle dequeuing of non queued request gracefully
Trying to dequeue an request that is currently not queued should be a no-op and be handled gracefully.
Checking on list/queue empty indicate whether the request is queue or not. Handling this gracefully allows for race condition free synchronization between the complete callback being called to to a completed transfer and trying to call usb_ep_dequeue() at the same time.
Inspired by: https://patchwork.kernel.org/project/linux-usb/patch/20191106144553.16956-1-...
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index eb416b832aa..378d19d8e99 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1113,6 +1113,9 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep,
spin_lock_irqsave(&dwc->lock, flags);
+ if (list_empty(&dep->request_list) && list_empty(&dep->req_queued)) + goto out0; + list_for_each_entry(r, &dep->request_list, list) { if (r == req) break;
Rasmus
Hi Rasmus,
Make sense to me. At least now I know that these messages are not a critical error and will not give me problems on the future.
Thanks for the patch too.
Regards, João Paulo
On Fri, 2023-09-15 at 15:47 +0200, Rasmus Villemoes wrote:
This message originated from outside your organization
On 15/09/2023 15.05, João Paulo Silva Gonçalves wrote:
Hi Marek,
I was testing fastboot image download over usb for imx8mp (from usb recovery patch of verdin-imx8mp) and i am having error messages on endpoint request dequeue function of DWC3 gadget controller. However, download is working fine, so this message may not be an error. They are happening because fastboot tx before sending a new usb request dequeue the same request, maybe to be sure it does not send it twice. Can I just ignore these messages? Maybe change its log level to dbg instead of error? What do you think? The messages I am seeing are below and are the ones with "... was not queued to ep1in-bulk".
We apply this internally (sorry if it's whitespace damaged), but I never fully understood the problem nor how the referenced kernel thread was resolved, which is why I haven't sent it upstream yet.
dwc3: gadget: Handle dequeuing of non queued request gracefully
Trying to dequeue an request that is currently not queued should be a no-op and be handled gracefully.
Checking on list/queue empty indicate whether the request is queue or not. Handling this gracefully allows for race condition free synchronization between the complete callback being called to to a completed transfer and trying to call usb_ep_dequeue() at the same time.
Inspired by: https://patchwork.kernel.org/project/linux-usb/patch/20191106144553.16956-1-...
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index eb416b832aa..378d19d8e99 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1113,6 +1113,9 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep,
spin_lock_irqsave(&dwc->lock, flags);
- if (list_empty(&dep->request_list) && list_empty(&dep->req_queued))
- goto out0;
list_for_each_entry(r, &dep->request_list, list) { if (r == req) break;
Rasmus
participants (2)
-
João Paulo Silva Gonçalves -
Rasmus Villemoes