On Thu, Jan 13, 2011 at 6:18 PM, Maulik Mankad <maulik@xxxxxx> wrote:
When USB CV MSC tests are run on f_mass_storage gadget
Bulk Only Mass Storage Reset fails since req->length
is set to USB_BUFSIZ=1024 in composite_setup().
Set req->length to zero since the reset request does not
contain any data transfers.
Signed-off-by: Maulik Mankad <maulik@xxxxxx>
Cc: Michal Nazarewicz <mina86@xxxxxxxxxx>
Cc: Felipe Balbi <balbi@xxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxx>
---
Update Michal's email address.
Yeah... I'm wondering if I should send a patch fixing my email in
source files.
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:
This really should be handled by Michal.
Yeah, sorry, I've just moved to Zurich so been postponing looking at
the code.
But AFAICS the fix is not correct. The whole DELAYED_STATUS definition
and interpretation needs to be put into the composite core.
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.
--
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
