On Sat, Apr 25, 2020 at 3:53 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 24 Apr 2020, Andrey Konovalov wrote: > > > On Fri, Apr 24, 2020 at 9:36 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote: > > > > Hi Alan, > > > > > > I've started working on a test suite for raw-gadget based on the > > > usbtest module as you suggested and have a few questions: > > > > > > 1. (Re test #10:) Currently there's no way to stall USB (control) > > > requests with raw-gadget (which is what happens when you return -EPIPE > > > from gadget's setup() callback AFAIU). Is stalling an important part > > > of the protocol? Should we somehow support it? AFAIU gadgetfs also has > > > no ability to stall requests that are passed to userspace. > > Yes, stalling is important, and you do need to support it. gadgetfs > does have a way to stall requests on ep0 from userspace: just perform > I/O in the "wrong" direction. If the host sends a control-IN request > and the user does a read of the ep0 file, or if the host sends a > control-OUT request and the user does a write, gadgetfs will call > usb_ep_set_halt. (However I do not remember how the setup_can_stall > flag is meant to work.) Ah, so halting ep0 after having successfully received a setup stage request (setup() callback returns 0) will result in a stall during the data stage (I hope I'm using those "stage" terms right) without the gadget needing to queue an URB as it happens during a normal response? Shouldn't this halt the endpoint until the user (or the gadget) unhalts it? Does this work when we want to just stall a single request? What happens with the requests that come after? > > > > 2. Re test #4: the test fails with length that is not divisible by > > > endpoint's max packet value when using dummy_hcd (assuming that gadget > > > keeps queueing URBs with max packet length), as dummy_hcd's transfer() > > > function sets status to -EOVERFLOW when this happens. Is this > > > expected? > > Yes, it is. If you want to avoid overflow errors, you have to set the > "vary" parameter to a multiple of the bulk-IN endpoint's maxpacket > value and the "length" parameter to a multiple of that. OK, got it. Those tests actually also fail with g_zero. I guess the way to use usbtest in a particular setup (with particular host and device controllers) is to first run the tests with e.g. g_zero, find the ones that fail, and don't run those with raw-gadget or whatever you're trying to test. > > > 3. Re test #7: the test fails when e.g. vary parameter is set to some > > > odd value when using dummy_hcd. AFAIU this happens since dummy_hcd > > > doesn't have no_sg_constraint flag set and therefore the sanity check > > > in usb_submit_urb() fails. Is this expected? > > No, I don't think so. Have you tried setting no_sg_constraint? > Probably we just forgot to do it. Will try. > > 4. Re test #13: it seems that both dummy_hcd and the UDC on Raspberry > > Pi Zero handle host driven endpoint halts themselves without any need > > to support them on the gadget side. Thus this test can't really be > > used to test the halt implementation I have for raw-gadget. Are there > > other ways to test it? > > Have you tried running the USBCV tests, available from usb.org? They > need a Windows host to run on but are otherwise pretty straightforward. > If a mass-storage gadget (like g-mass-storage) can pass the USBCV > Mass-Storage test, for example, that's a pretty stringent verification. > > Try them on any userspace gadget drivers you have lying around. Didn't yet get to those, I'll try them too. Thanks!
