[PATCH] usb: gadget: fastboot: avoid stale IN dequeue

Sam Day me at samcday.com
Mon Jun 1 00:55:19 CEST 2026


Hello Marek,

On Monday, 1 June 2026 at 7:43 AM, Marek Vasut <marek.vasut at mailbox.org> wrote:

> On 5/31/26 9:01 AM, Sam Day wrote:
> > This usb_ep_dequeue line was originally added as a fix specifically for
> > MUSB UDCs.
> >
> > On dwc3, it causes an error like this to be logged:
> >
> > ```
> > dwc3-generic-peripheral usb at a600000: request 000000016e0862
> > c0 was not queued to ep1in-bulk
> > ```
> >
> > The trouble is, this causes an infinite loop in `fastboot oem console`.
> > Every time it flushes out a response with a chunk of the console, it
> > triggers another instance of this error, which means another response
> > must be written, which generates the error, and so on.
> >
> > I'm not sure if the MUSB gadget code still needs this workaround, so to
> > be safe I opted not to remove it, but guard it with
> > CONFIG_USB_MUSB_GADGET instead.
> >
> > Signed-off-by: Sam Day <me at samcday.com>
> > ---
> >   drivers/usb/gadget/f_fastboot.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
> > index 8df0e3f331d..fb7e47401ca 100644
> > --- a/drivers/usb/gadget/f_fastboot.c
> > +++ b/drivers/usb/gadget/f_fastboot.c
> > @@ -406,7 +406,8 @@ static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
> >   	memcpy(in_req->buf, buffer, buffer_size);
> >   	in_req->length = buffer_size;
> >
> > -	usb_ep_dequeue(fastboot_func->in_ep, in_req);
> > +	if (IS_ENABLED(CONFIG_USB_MUSB_GADGET))
> > +		usb_ep_dequeue(fastboot_func->in_ep, in_req);
> This won't work on systems that have multiple disparate USB controllers.

I think I follow you, but could you please expand on this a little so I'm
not guessing as to what you mean?

My understanding is you're saying this won't work if one builds with two
different UDC drivers enabled, one being MUSB.

That's true, and in that case fastboot might continue to cause issues. As I
noted in the original patch, I have no idea if MUSB still needs this workaround
introduced 10+ years ago, I don't have any MUSB hardware to test on.

Or are you suggesting that introducing this gating on Kconfig symbol is broken?

> 
> Why was the workaround added in the first place ?
> 
It was introduced by bc9071c9f318, which specifically spoke about MUSB issues.

-Sam



More information about the U-Boot mailing list