Hello Lothar and Mattijs, I hope web outlook doesn't render my response unreadable. ________________________________________ From: Mattijs Korpershoek <[email protected]> Sent: Thursday, July 9, 2026 17:15 To: Lothar Waßmann; [email protected] Cc: Petr Beneš Subject: Re: Regression in f_fastboot due to commit 6a92e9827650 ("usb: ci_udc: Check ci_ep->desc before use")
Hi Lothar, On Wed, Jul 08, 2026 at 07:12, Lothar Waßmann <[email protected]> wrote: > Hi, > > commit 6a92e9827650 ("usb: ci_udc: Check ci_ep->desc before use") has > the side effect that an empty buffer is being passed on to > rx_handler_command() in drivers/usb/gadget/f_fastboot.c upon > termination of a fastboot session which leads to a > 'command not recognized' error message being printed on the console. Thank you for reporting this. > > Obviously without the commit the offending USB request had been silently > dropped but is now delivered to the upper levels. Well, it was not silently dropped in case of the ethernet gadget, it was silently corrupting memory. > > I'm not sure what the correct fix would be. > Should the fastboot driver ignore the empty command buffer or should > the "Moreover, the patch gets rid of possible outstanding requests > if the endpoint's state changes to disabled." part of the commit be > reverted? Hmm, maybe I got it wrong. The endpoint got disabled, so what should happen with requests? linux/usb/gadget.h reads: * @complete: Function called when request completes, so this request and * its buffer may be re-used. * Reads terminate with a short packet, or when the buffer fills, * whichever comes first. When writes terminate, some data bytes * will usually still be in flight (often in a hardware fifo). * Errors (for reads or writes) stop the queue from advancing * until the completion function returns, so that any transfers * invalidated by the error may first be dequeued. Petr, did you observe similar behaviour with the ums gadget? I didn't see any wrongdoing of the ethernet gadget. > > > Lothar Waßmann Regards, Petr
