All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Konovalov <andreyknvl@google.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	USB list <linux-usb@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: Testing endpoint halt support for raw-gadget
Date: Sat, 25 Apr 2020 16:49:31 +0200	[thread overview]
Message-ID: <CAAeHK+z5DXp9HL+=9z2cEOHpBUuhAV_EmDHucyc4+GtSaYJFjg@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.2004242118210.17660-100000@netrider.rowland.org>

On Sat, Apr 25, 2020 at 3:53 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, 24 Apr 2020, Andrey Konovalov wrote:
>
> > On Fri, Apr 24, 2020 at 9:36 PM Andrey Konovalov <andreyknvl@google.com> 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!

  reply	other threads:[~2020-04-25 14:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09 16:48 Testing endpoint halt support for raw-gadget Andrey Konovalov
2020-04-10  0:29 ` Alan Stern
2020-04-10 15:13   ` Andrey Konovalov
2020-04-10 15:53     ` Alan Stern
2020-04-27  1:26       ` Peter Chen
2020-04-27 14:29         ` Alan Stern
2020-04-29  2:20       ` Andrey Konovalov
2020-04-29 14:06         ` Alan Stern
2020-05-04 14:16           ` Andrey Konovalov
2020-05-04 14:24             ` Alan Stern
2020-05-04 15:11               ` Andrey Konovalov
2020-05-04 15:15                 ` Alan Stern
2020-05-05  6:34                   ` Felipe Balbi
2020-05-05 12:13                     ` Andrey Konovalov
2020-05-05 16:42                       ` Thinh Nguyen
2020-05-05  6:30               ` Felipe Balbi
2020-04-24 19:36   ` Andrey Konovalov
2020-04-24 19:56     ` Andrey Konovalov
2020-04-25  1:53       ` Alan Stern
2020-04-25 14:49         ` Andrey Konovalov [this message]
2020-04-25 15:02           ` Alan Stern
2020-04-27 19:51     ` Andrey Konovalov
2020-04-27 20:47       ` Andrey Konovalov
2020-04-28  0:50         ` Andrey Konovalov
2020-04-28  1:32           ` Andrey Konovalov
2020-04-28 13:27             ` Alan Stern
2020-05-13 17:07               ` Andrey Konovalov
2020-05-13 18:14                 ` Alan Stern
2020-05-13 18:31                   ` Andrey Konovalov
2020-05-13 19:09                     ` Alan Stern
2020-05-13 19:38                       ` Andrey Konovalov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAeHK+z5DXp9HL+=9z2cEOHpBUuhAV_EmDHucyc4+GtSaYJFjg@mail.gmail.com' \
    --to=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.