On Wed, 19 Jan 2011 17:33:56 +0100, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
wrote:
On Wed, 19 Jan 2011, Michal Nazarewicz wrote:
"Mankad, Maulik Ojas" <maulik@xxxxxx> writes:
> What I have observed while debugging is with MSF when BOT MSC reset is
> issued, composite_setup() ends up calling fsg_setup().
> Note that req->length is set to USB_BUFSIZ = 1024 in
composite_setup().
>
> While handling this class specific request, ep0_queue() gets called
> under FSG_STATE_RESET case of handle_exception() function.
> Thus ep0_queue() gets called with req->length set to 1024. Hence the
> controller driver reports a timeout error on endpoint zero.
OK, that makes sense. I'd put a "common->ep0req->length = 0;" line in
handle_exception() though, just before ep0_queue().
Why not also change composite_setup()? What on earth is the purpose of
the "req->length = USB_BUFSIZ;" line near the start? That must be the
wrong value more than 99% of the time. Especially since near the end
of the routine, there's another line setting req->length to the correct
value just before it gets used.
I'm wondering whether the idea wasn't to state the size of the buffer for
functions. This may be especially true since the USB_BUFSIZE is defined
in composite.c rather than any header file so I would imagine that it is
not a public interface but gets pulled to gadgets drivers only because
they all #include all the .c files involved.
In fact, I'd favor changing the "USB_BUFSIZ" in the first line to "0".
But that's only a matter of personal preference.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
