From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Michal Necasek <michal.necasek@oracle.com>, mathias.nyman@intel.com
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Dennis Wassenberg <dennis.wassenberg@secunet.com>
Subject: Re: xhci_reset_endpoint() doesn't reset endpoint
Date: Wed, 14 Dec 2016 16:28:40 +0200 [thread overview]
Message-ID: <58515718.50309@linux.intel.com> (raw)
In-Reply-To: <7baa1154-5c0e-4c07-88e7-3e532404b69a@default>
On 14.12.2016 12:58, Michal Necasek wrote:
> prior to the endpoint reset. SetFeature(CLEAR_HALT) resets the toggle
> on the device, but not on the host. But we know for a fact that the
> device sends a packet (with data toggle 0) which the host USB stack
> never sees, and a data toggle mismatch explains that quite well.
>
> We are using USBFS to talk to the printer, but that shouldn't matter
> much. I will note that the available documentation<1> explicitly says
> that USBDEVFS_RESETEP and USBDEVFS_CLEAR_HALT both reset the data
> toggle. That is indeed the case for the Linux EHCI driver but not
> xHCI. Both of the USBFS IOCTLs call into xhci_reset_endpoint() which
> does nothing.
>
This is very likely the case.
xhci can not reset the host side of the endpoint unless it really is halted.
xhci 4.6.8:
"If the endpoint is not in the Halted state when an Reset Endpoint Command
is executed -The xHC shall reject the command and generate a Command
Completion Event with the Completion Code set to Context State Error."
Normal halt/stall case is that xhci receives a STALL from the device,
and immediately resets the endpoint (clears toggle, host side) then
propagates the HALT status to usb core.
USB core then sends SetFeature(CLEAR_HALT) to the device which will reset the
toggle for the device side of the endpoint, and host and device toggles
will be in sync.
After this xhci_endpoint_reset() is called by usb core to inform xhci that the
endpoint was reset, but currently we don't do anything in it.
If SetFeature(CLEAR_HALT) is called without endpoint actually being HALTED we can not
reset it from xhci. we should issue a config endpoint command to reset the host side
toggle, as mentioned in xhci 1.0 120814 as a last note:
"Note: The Reset Endpoint Command may only be issued to endpoints in the Halted state.
If software wishes reset the Data Toggle or Sequence Number of an endpoint that isn't
in the Halted state, then software may issue a Configure Endpoint Command with the Drop
and Add bits set for the target endpoint. that is in the Stopped state."
There was a case with a scanner we believed had the same issue, and we tried to
resolve it by issuing the configure endpoint command in xhci_endpoint_reset() but
if I remember correctly It did not resolve the case and code never got anywhere.
I might have some really old implementation somewhere for this, at least there is
a really old and outdated hack at
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test
https://git.kernel.org/cgit/linux/kernel/git/mnyman/xhci.git/log/?h=ep_reset_halt_test
which really is quite a hack, and based on 3.19 kernel so it's probably only useful
as an Idea to base a real solution on.
-Mathias
next prev parent reply other threads:[~2016-12-14 14:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 10:58 xhci_reset_endpoint() doesn't reset endpoint Michal Necasek
2016-12-14 14:28 ` Mathias Nyman [this message]
2016-12-15 15:42 ` Michal Necasek
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=58515718.50309@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=dennis.wassenberg@secunet.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=michal.necasek@oracle.com \
/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