From: Peter Chen <peter.chen@nxp.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: Testing endpoint halt support for raw-gadget
Date: Mon, 27 Apr 2020 01:26:55 +0000 [thread overview]
Message-ID: <20200427012719.GA6782@b29397-desktop> (raw)
In-Reply-To: <Pine.LNX.4.44L0.2004101136490.15021-100000@netrider.rowland.org>
On 20-04-10 11:53:20, Alan Stern wrote:
> On Fri, 10 Apr 2020, Andrey Konovalov wrote:
>
> > On Fri, Apr 10, 2020 at 2:29 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> > > Have you implemented wedge as well as halt? Wedge is needed for the
> > > mass-storage protocol; as far as I know it isn't used anywhere else.
> >
> > No, I didn't know about "wedge" at all :) Looks like the API for it is
> > really simple, just usb_ep_set_wedge(). I'll need to figure out what
> > it is and how it works, and I'll send a patch that adds halt/wedge
> > support then.
>
> usb_ep_set_wedge(ep) does almost the same thing as
> usb_ep_set_halt(ep). The difference is that a Clear-Feature(halt)
> request from the host will un-halt an endpoint if it is merely halted,
> but it won't un-halt a wedged endpoint. (I don't think this is
> documented anywhere, unfortunately.)
Hi Alan,
It is documented at drivers/usb/gadget/udc/core.c, function
usb_ep_set_wedge.
--
Thanks,
Peter Chen
next prev parent reply other threads:[~2020-04-27 1:27 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 [this message]
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
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=20200427012719.GA6782@b29397-desktop \
--to=peter.chen@nxp.com \
--cc=andreyknvl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox