linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Felipe Balbi <balbi@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org,
	Mathias Nyman <mathias.nyman@intel.com>
Cc: John Youn <John.Youn@synopsys.com>
Subject: Re: [PATCH v2 6/7] usb: xhci: Workaround lost disconnect port status
Date: Wed, 28 Apr 2021 16:48:23 +0300	[thread overview]
Message-ID: <37b09a1a-d2f7-c152-0850-20215822ff1d@linux.intel.com> (raw)
In-Reply-To: <a90cfd8e3008c3664a916a12dc3c0a79a520c0ab.1618014279.git.Thinh.Nguyen@synopsys.com>

On 10.4.2021 3.47, Thinh Nguyen wrote:
> If an eSS device with active periodic transfers is disconnected from the
> DWC_usb31 (v1.90a and prior) host controller at root port, the host
> controller may not detect a disconnection. By active transfers, it
> means that the endpoint is not in flow control, and there are active
> Transfer Descriptors available for the host to initiate transfers to the
> endpoint. This issue can occur if the endpoint periodic interval is in
> 2ms, 4ms, or 8ms.
> 
> In addition, the host controller will not be able to detect a new device
> connection while the disconnection is not processed. The controller will
> set the link state of the affected port to eSS_INACTIVE.
> 
> To workaround this, have the xHCI driver polls for the eSS root port
> status every 2 seconds. If eSS_INACTIVE state is detected, initiate a
> fake connection change to stop all the active endpoints and start
> polling for new connection change.


If this only happens with active periodic transfers can we skip the polling
and check port link state in the transfer error event handling?

Like in the previous case there the periodic device was behind a hub.

-Mathias

  reply	other threads:[~2021-04-28 13:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-09  1:41 [PATCH 0/6] usb: Set quirks for xhci/dwc3 host mode Thinh Nguyen
2021-04-09  1:41 ` [PATCH 1/6] usb: xhci: Move quirks definitions to common usb header Thinh Nguyen
2021-04-09  6:50   ` Greg Kroah-Hartman
2021-04-09  8:01     ` Thinh Nguyen
2021-04-09 16:26   ` kernel test robot
2021-04-09 19:54   ` kernel test robot
2021-04-09  1:42 ` [PATCH 2/6] usb: xhci: Check for blocked disconnection Thinh Nguyen
2021-04-09  1:42 ` [PATCH 3/6] usb: xhci: Workaround undercalculated BW for fullspeed BI Thinh Nguyen
2021-04-09  1:42 ` [PATCH 4/6] usb: xhci: Rename Compliance mode timer quirk Thinh Nguyen
2021-04-09  1:42 ` [PATCH 5/6] usb: xhci: Workaround lost disconnect port status Thinh Nguyen
2021-04-09  1:42 ` [PATCH 6/6] usb: dwc3: host: Set quirks base on version Thinh Nguyen
2021-04-09  6:53   ` Greg Kroah-Hartman
2021-04-09  8:01     ` Thinh Nguyen
2021-04-09 13:22       ` Greg Kroah-Hartman
2021-04-10  0:44         ` Thinh Nguyen
2021-04-10  0:46 ` [PATCH v2 0/7] usb: Set quirks for xhci/dwc3 host mode Thinh Nguyen
2021-04-10  0:46   ` [PATCH v2 1/7] usb: xhci: Move quirks definitions to common usb header Thinh Nguyen
2021-04-10  0:46   ` [PATCH v2 2/7] usb: xhci: Move xhci-plat header " Thinh Nguyen
2021-04-10  0:47   ` [PATCH v2 3/7] usb: xhci: Check for blocked disconnection Thinh Nguyen
2021-04-27 13:08     ` Mathias Nyman
2021-04-27 22:30       ` Thinh Nguyen
2021-04-28 13:32         ` Mathias Nyman
2021-04-29  0:54           ` Thinh Nguyen
2021-04-10  0:47   ` [PATCH v2 4/7] usb: xhci: Workaround undercalculated BW for fullspeed BI Thinh Nguyen
2021-04-28 11:57     ` Mathias Nyman
2021-04-10  0:47   ` [PATCH v2 5/7] usb: xhci: Rename Compliance mode timer quirk Thinh Nguyen
2021-04-10  0:47   ` [PATCH v2 6/7] usb: xhci: Workaround lost disconnect port status Thinh Nguyen
2021-04-28 13:48     ` Mathias Nyman [this message]
2021-04-29  1:00       ` Thinh Nguyen
2021-04-10  0:47   ` [PATCH v2 7/7] usb: dwc3: host: Set quirks base on version Thinh Nguyen
2021-04-19 21:07   ` [PATCH v2 0/7] usb: Set quirks for xhci/dwc3 host mode Thinh Nguyen

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=37b09a1a-d2f7-c152-0850-20215822ff1d@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=John.Youn@synopsys.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.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;
as well as URLs for NNTP newsgroup(s).