On Wed, 18 Jan 2012, Sebastian Andrzej Siewior wrote: > >>> In fact, this sounds like a weakness in the target layer. A transport > >>> driver should be able to ask the target layer how much data should be > >>> transferred for a command, and in which direction. > >> > >> Yes, and this is why I have this lookup table. It was initially > >> submitted as an extension to target but since I'm the only user it was > >> moved into the gadget. Maybe it can be moved into drivers/scsi since > >> there are other drivers having another lookup table. > > > > I think there are a few commands which have variant meanings, depending > > on the type of the device. It would be difficult to express that in a > > simple table. > > Okay. So embedding the direction flag into the cdb handling is a > possible way. The best approach would be something like what Nicholas said. The target layer should provide an API for getting the expected length and direction of a command. > >> If I send not > >> enough data then it will notice it soon because the status URB arrives > >> before the data URB completes. > > > > And then what happens? Does the host driver compute the difference and > > report it as the residue? > > The host side sets residue via > > sdb->resid = sdb->length - urb->actual_length; > > once the data urb completes which is before the status urb (end) > arrives. Why does the host's data URB complete? Does the device always terminate the transfer with a short packet if the amount of data it sends is smaller than the host expects to receive? How does the device know how much the host expects? > > What if you want to receive too little data? > > Don't get it. But you send a smaller URB then. But then you'll send a status URB response at a time when the host is still trying to send data. What will the host do if its status URB completes before its data URB? 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