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. > Besides, you may need to consider high bandwidth ISO transfer, > you can send the formal patch and I will change gadget side > and have a test. I'm not so sure we ought to change this. > 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. > 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. 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
