From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: mathias.nyman@intel.com, Greg KH <gregkh@linuxfoundation.org>,
USB <linux-usb@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Mark Brown <broonie@kernel.org>
Subject: Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command
Date: Thu, 1 Dec 2016 15:28:25 +0200 [thread overview]
Message-ID: <58402579.6000308@linux.intel.com> (raw)
In-Reply-To: <CAMz4kuKOhsCQUn8TBMpcY7jefKZhnpGee2o50P2DTDp9-Yn6xA@mail.gmail.com>
On 01.12.2016 06:54, Baolin Wang wrote:
> On 30 November 2016 at 22:09, Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
>> On 30.11.2016 11:02, Baolin Wang wrote:
>>>
>>> If the hardware never responds to the stop endpoint command, the
>>> URBs will never be completed, and we might hang the USB subsystem.
>>> The original watchdog timer is used to watch if one stop endpoint
>>> command is timeout, if timeout, then the watchdog timer will set
>>> XHCI_STATE_DYING, try to halt the xHCI host, and give back all
>>> pending URBs.
>>>
>>> But now we already have one command timer to control command timeout,
>>> thus we can also use the command timer to watch the stop endpoint
>>> command, instead of one duplicate watchdog timer which need to be
>>> removed.
>>>
>>> Meanwhile we don't need the 'stop_cmds_pending' flag to identy if
>>> this is the last stop endpoint command of one endpoint. Since we
>>> can make sure we only set one stop endpoint command for one endpoint
>>> by 'EP_HALT_PENDING' flag in xhci_urb_dequeue() function. Thus remove
>>> this flag.
>>>
>>> We also need to clean up the command queue before trying to halt the
>>> xHCI host in xhci_stop_endpoint_command_timeout() function.
>>
>>
>> This isn't a bad idea.
>>
>> There are anyway some corner cases and details that need to be
>> checked, such as suspend (which will clear the command queue), module unload
>> and abrupt host removal (like pci hotplug removal of host controller)
>> we need to make sure we can trust the command timer to always return the
>> canceled URB
>
> Yes, you are right, we need to check these carefully.
>
> Suspend process, module unload and abrupt host removal, they all will
> issue usb_disconnect() firstly before clear the command queue, it will
> check URBs for every endpoint by
> usb_disconnect()--->usb_disable_device()--->usb_disable_endpoint(),
> which will make sure every URBs of endpoints will be cancelled by the
> stop endpoint command responding or the timeout function of stop
> endpoint command (xhci_stop_endpoint_command_timeout()) in
> usb_hcd_flush_endpoint(). From that point, we can make sure the
> command timer will be useful to handle stop endpoint command timeout.
> Please correct me if I said something wrong. Thanks.
>
This relies on current queued command that times out to be the stop endpoint command.
If host partially, or completely hangs there might be any number of commands in the
command queue, and we would need to wait for each one of them to timeout, finish
before we finally get to the stop endpoint command, and give back the urb.
I think it would be better to first fix the issues with the current watchdog function, get
those fixes into stable, and then think about moving to the command queue timer.
In short, this patch doesn't currently fix any existing issue, but might cause the
timeout to be more unreliable
-Mathias
next prev parent reply other threads:[~2016-12-01 13:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 9:02 [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command Baolin Wang
2016-11-30 14:09 ` Mathias Nyman
2016-12-01 4:54 ` Baolin Wang
2016-12-01 13:28 ` Mathias Nyman [this message]
2016-12-02 2:46 ` Baolin Wang
2016-12-01 5:45 ` Lu Baolu
2016-12-01 6:04 ` Baolin Wang
2016-12-01 6:09 ` Baolin Wang
2016-12-01 6:35 ` Lu Baolu
2016-12-01 7:35 ` Baolin Wang
2016-12-01 7:44 ` Lu Baolu
2016-12-01 8:03 ` Baolin Wang
2016-12-02 1:17 ` Lu Baolu
2016-12-02 2:48 ` Baolin Wang
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=58402579.6000308@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=baolin.wang@linaro.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.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 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.