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.) > > 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. > > 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. > 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. Alan Stern
