On Wed, 23 Mar 2011, Roger Quadros wrote: > > On the other hand, I don't think any implementations would get upset if > > we simply ended the transfer with a short packet instead of adhering > > strictly to the spec. > > > > The patch below should do what you want. I haven't tested it. > > I tried your patch with the CD-ROM implementation and it works perfectly. I do > not see the unnecessary zero padded transfers any more. > > Do you think we should have this patch in? with the risk of not strictly > adhering to spec for cases where controller cannot stall? There already is another place where not stalling forces the driver to violate the spec. I don't think this makes things much worse... but it is a significant change in behavior. This affects Michal's driver too; we should ask his opinion. Michal, in case you didn't see it, the proposed patch is here: http://marc.info/?l=linux-usb&m=130080683528607&w=2 > Maybe the term "controller cannot stall" itself does not adhere to bulk-only > transport spec :). True enough. However I believe USB flash drives behave this way: They don't stall and they don't pad their data. > > @@ -1710,24 +1683,19 @@ static int finish_reply(struct fsg_commo > > common->next_buffhd_to_fill = bh->next; > > > > /* > > - * For Bulk-only, if we're allowed to stall then send the > > - * short packet and halt the bulk-in endpoint. If we can't > > - * stall, pad out the remaining data with 0's. > > + * For Bulk-only, mark the end of the data with a short > > + * packet. If we are allowed to stall, halt the bulk-in > > + * endpoint. (Note: This violates the Bulk-Only Transport > > + * specification, which requires us to pad the data if we > > violates the spec only if we are not allowed to stall (i.e. stall=n) right? Right. > > + * don't halt the endpoint. Presumably nobody will mind.) > > */ 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
