2011/1/19 Michal Nazarewicz <mina86@xxxxxxxxxx>: >>>> On Thu, Jan 13, 2011 at 6:18 PM, Maulik Mankad <maulik@xxxxxx> wrote: >>>>> Rebased to Linus's master. >>>>> >>>>> drivers/usb/gadget/f_mass_storage.c | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> Index: mainline/drivers/usb/gadget/f_mass_storage.c >>>>> =================================================================== >>>>> --- mainline.orig/drivers/usb/gadget/f_mass_storage.c >>>>> +++ mainline/drivers/usb/gadget/f_mass_storage.c >>>>> @@ -626,6 +626,7 @@ static int fsg_setup(struct usb_function >>>>> * and reinitialize our state. >>>>> */ >>>>> DBG(fsg, "bulk reset request\n"); >>>>> + fsg->common->ep0req->length = 0; >>>>> raise_exception(fsg->common, FSG_STATE_RESET); >>>>> return DELAYED_STATUS; >>>>> > >>> On Tue, 18 Jan 2011 16:14:07 +0100, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> >>> wrote: >>>> But AFAICS the fix is not correct. The whole DELAYED_STATUS definition >>>> and interpretation needs to be put into the composite core. > >> 2011/1/19 Michal Nazarewicz <mina86@xxxxxxxxxx>: >>> Actually I think that handling of DELAYED_STATUS is pretty much the same in >>> FSG and MSF. In FSG no request is queued and the DELAYED_STATUS is returned >>> back to the UDC driver and the same things happens in MSF since composite >>> does not queue any requests in the "non-core control request" path but just >>> returns what ->setup() yields. >>> >>> Still, I'm not entirely sure how the above change affects anything since no >>> one should touch the ep0req after fsg_setup() returns. > > "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(). > If everyone is aligned I shall post a V3 with your suggested change. Regards, Maulik -- 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
