From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Linux USB <linux-usb@vger.kernel.org>,
John Youn <John.Youn@synopsys.com>
Cc: stable@vger.kernel.org
Subject: Re: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid
Date: Tue, 04 Apr 2017 11:09:04 +0300 [thread overview]
Message-ID: <877f30iogv.fsf@linux.intel.com> (raw)
In-Reply-To: <20170119114034.15184-1-felipe.balbi@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]
Hi John,
Felipe Balbi <felipe.balbi@linux.intel.com> writes:
> At least macOS seems to be sending
> ClearFeature(ENDPOINT_HALT) to endpoints which
> aren't Halted. This makes DWC3's CLEARSTALL command
> time out which causes several issues for the driver.
>
> Instead, let's just return 0 and bail out early.
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
> ---
>
> this falls into "has never worked before" category, so I'll be sending
> it together with other patches for v4.11 merge window. Still, it's a
> valid bug that's likely needed for stable trees.
>
> drivers/usb/dwc3/gadget.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 6faf484e5dfc..0a664d8eba3f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
> unsigned transfer_in_flight;
> unsigned started;
>
> + if (dep->flags & DWC3_EP_STALL)
> + return 0;
> +
> if (dep->number > 1)
> trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
> else
> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
> else
> dep->flags |= DWC3_EP_STALL;
> } else {
> + if (!(dep->flags & DWC3_EP_STALL))
> + return 0;
>
> ret = dwc3_send_clear_stall_ep_cmd(dep);
> if (ret)
Reviving this old thread here. While $subject allowed dwc3 to work when
attached to macOS Host, I fear that we might have more issues than not
in the future. The reason is that USB20 spec allows hosts to use
ClearFeature(ENDPOINT_HALT) as a "Reset Data Toggle/SeqN" hint.
With this, we're basically blocking that possibility. Still, without
$subject, ClearStall commands were timing out. I'll try to do a local
revert here and check what happens in this case, but would you have any
idea why ClearStall would time out like that?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-04-04 8:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 11:40 [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid Felipe Balbi
[not found] ` <30102591E157244384E984126FC3CB4F2FF567F3@US01WEMBX2.internal.synopsys.com>
2017-03-08 9:29 ` Felipe Balbi
2017-03-08 9:33 ` Felipe Balbi
2017-03-08 11:29 ` Felipe Balbi
2017-03-08 11:55 ` Felipe Balbi
2017-04-04 8:09 ` Felipe Balbi [this message]
2017-04-04 15:53 ` John Youn
2017-04-05 8:31 ` Felipe Balbi
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=877f30iogv.fsf@linux.intel.com \
--to=felipe.balbi@linux.intel.com \
--cc=John.Youn@synopsys.com \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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.