On Mon, 24 Aug 2015, Felipe Balbi wrote: > > Maybe we should add a vendor-specific control request to gadget Zero so > > that the host can tell the gadget what the transfer size will be. > > I proposed that many months ago and you were against it, remember ? I believe you -- it sounds like the sort of thing I might say -- but I don't remember it. :-) > You claimed that there should be no issues with gadget and host not > agreeing on transfer size, which actually makes sense, considering we > have no idea what the host will send us until it does (except for things > like BOT). > > If we add this vendor control request, we are likely to leave some > issues in UDCs making assumptions as to what they should receive next. These are good arguments. The only place an issue arises, as far as I can see, is in the pattern=2 data. Where should the pattern reset back to the start? At the beginning of each packet? At the beginning of each transfer? At the beginning of each test? The difficulty is that the host and gadget don't have any common notions about transfers or tests. That leaves only packets (or maybe bursts/multiplets for isochronous). > > > Besides, if I use vary < length, the test 4/7/8 have failed > > > (still not check why) > > > > Test 7 should be okay, since it involves OUT transfers. Tests 4 and 8 > > involve IN transfers, so they will run into trouble unless vary is a > > multiple of the maxpacket size. Otherwise the host will expect a short > > packet at the end of some of the transfers, but the gadget will not > > send any short packets. > > we could add some argument sanity checks to usbtest.ko to make sure > arguments make sense. It might help a little. You'd still get a failure, but the error code would indicate that it was your mistake and not a driver problem. > > > Besides, considering let vary equals to length for control > > > transfer? In that case, we can use one line command for all tests. > > > > I don't know. For some tests, it may make sense to require the > > parameters to have special values, so that the host side will agree > > with the gadget side. > > but why does the host need to agree with the gadget side ? Let's > consider a bogus host, for example, talking to a BOT device. Say CBW > states it will read 8192 bytes from device, but host ends up trying to > read a different amount of bytes. The BOT device is not expected to > simply die, it will either refuse to send more data with a NAK or wait > for a further request to move the remaining amount. Yes, they don't need to agree for a MSC test. But they do need to agree for simple read/write tests with pattern=2. Otherwise the test will fail, because the sender will generate a pattern that the receiver doesn't expect. 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
