On Mon, Aug 24, 2015 at 11:43:21AM -0400, Alan Stern wrote: > On Mon, 24 Aug 2015, Peter Chen wrote: > > > On Thu, Aug 20, 2015 at 05:03:46PM -0400, Alan Stern wrote: > > > On Thu, 20 Aug 2015, Felipe Balbi wrote: > > > > > > > > > > - When using pattern = 1 as module parameters to compare the data, the > > > > > > > packet size must be same between host and device's. > > > > > > > > > > > > why ? > > > > > > > > > > The gadget stores the pattern data starting from 0 for each packet it > > > > > sends. But the host tests the pattern data starting from 0 only at the > > > > > beginning of the transfer; the host expects the pattern to continue > > > > > without resetting at packet boundaries (if the transfer length is > > > > > larger than the maxpacket size). > > > > > > > > then that's another bug which needs to be fixed :-) > > > > > > Here's my attempt at a fix. Completely untested, but it does compile > > > without errors. Peter, do you mind trying this out? > > > > After adding related changes at gadget side, it works. > > > > In fact, the gadget stores the pattern data starting from 0 to > > transfer length (not the packet length). > > This is the problem you were originally complaining about -- the > pattern test fails if the transfer length (not the packet length) is > different on the host and the gadget sides. > > I think it may make sense to require the transfer length to be the same > on both sides. That will mean the pattern gives a more stringent test. > With the change we have been discussing, all the packets will contain > exactly the same pattern -- that means the test is weaker. > > 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 ? 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. > > 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. > > 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
