On Thu, 24 Feb 2011, Michal Nazarewicz wrote: > > On Tue, Feb 22, 2011 at 8:49 PM, Alan Stern wrote: > >> In principle, function drivers -- including f_mass_storage -- > >> shouldn't depend on req->length being set to anything. A little > >> auditing would be a good idea. > > On Thu, 24 Feb 2011 12:58:22 +0100, Maulik Mankad > <mankad.maulik@xxxxxxxxx> wrote: > > I didn't quite understand your last point. > > > > This test works for g_file_storage gadget since "fsg->ep0req->length = > > 0" in fsg_setup() function in file_storage.c. > > > > Does setting "req->length= 0" in composite_setup() in f_mass_storage.c > > have any unwanted side effect? > > > > Should this change be done in the f_mass_storage.c under "case > > FSG_STATE_RESET" just before ep0_queue() is called (since we know that > > RESET request does not have a data phase)? > > Alan point is that your patch is correct. Composite functions should not > depend on value of req->length, so if your patch breaks some functions > its the function that need to be fixed. What could be handy is trying > to check in advance if any functions in fact depend on req->length. Exactly. Maulik, you determined that f_mass_storage works okay with your patch. But what about the other function drivers? Did you check to make sure the patch won't break any of them? Alan Stern -- 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
