From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Joel Stanley <joel@jms.id.au>, linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org
Subject: Re: [RFC PATCH] xhci: do not halt the secondary HCD
Date: Mon, 19 Sep 2016 10:41:15 +0300 [thread overview]
Message-ID: <57DF969B.8030204@linux.intel.com> (raw)
In-Reply-To: <20160919063545.2055-1-joel@jms.id.au>
On 19.09.2016 09:35, Joel Stanley wrote:
> We can't halt the secondary HCD, because it's also the primary HCD,
> which will cause problems if we have devices attached to the primary
> HCD, like a keyboard.
>
> We've been carrying this in our Linux-as-a-bootloader environment for a little
> while now. The machines all have the same TI TUSB73x0 part, and when we kexec
> the devices don't come back until a system power cycle.
>
> I'd like some advice on an acceptable way to upstream the fix, so that the xhci
> device survives kexec.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
What kernel version is this?
As Greg said there are fixes in this area in the 4.8 latest rc kernel.
If that doesn't work then we need to figure out what the real issue is.
xhci hardware is really just one controller. The split into primary and secondary HCD
is a software only. We always load the primary HCD first (USB2) and secondary second (USB3).
We unload them in reverse order, and need to stop the xhci (halt the hcd) as a first step.
load primary
load secondary (starts the xhci controller
...
unload secondary (halts the controller)
unload primary (free memory)
-Mathias
next prev parent reply other threads:[~2016-09-19 7:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 6:35 [RFC PATCH] xhci: do not halt the secondary HCD Joel Stanley
2016-09-19 7:03 ` Greg KH
2016-09-19 7:41 ` Mathias Nyman [this message]
2016-09-19 8:23 ` Joel Stanley
2016-09-20 8:26 ` Mathias Nyman
2016-10-26 4:27 ` Joel Stanley
2016-09-19 10:22 ` Sergei Shtylyov
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=57DF969B.8030204@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@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 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).