From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Puma Hsu <pumahsu@google.com>, Greg KH <gregkh@linuxfoundation.org>
Cc: mathias.nyman@intel.com, Sergey Shtylyov <s.shtylyov@omp.ru>,
Albert Wang <albertccwang@google.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3] xhci: re-initialize the HC during resume if HCE was set
Date: Mon, 17 Jan 2022 14:22:10 +0200 [thread overview]
Message-ID: <fe411488-c67c-62ab-4709-98621b9f199b@linux.intel.com> (raw)
In-Reply-To: <CAGCq0LZ3i8VaMfRWNKvH_-ms0TgNqKA6f+Zx7M=iz1t_-smW+g@mail.gmail.com>
>>> This seems like a big hammer for when the host controller throws an
>>>> error. Why is this the only place that it should be checked for? What
>>>> caused the error that can now allow it to be fixed?
>>>
>>> I believe this is not the only place that the host controller may set
>>> HCE, the host controller may set HCE anytime it sees an error in my
>>> opinion, not only in suspend or resume.
>>
>> Then where else should it be checked? Where else will your silicon set
>> this bit as part of the normal operating process?
>
> We observed this flag while resume in our silicon so far. According to the XHCI
> specification 4.24.1, “Software should implement an algorithm for checking the
> HCE flag if the xHC is not responding.”, so maybe it would be better
> to implement
> a new API to recover host controller whenever the driver side finds no response
> from host controller in the future.
>
As all the code to reset the host during resume already exists, and is well tried
due to issues in resume being so common, I think it makes sense to add the HCE case
here as well. It's a simple fix that makes the life of users better.
That said we shouldn't hide the reason for reset like this.
Print a debug message telling about the HCE so that everybody working with xHCI
can see it and start fixing the rootcause.
Another HCE check could be added to command timeout code, but just to show a
warning for now.
Reset might not always clear HCE, and we don't want to be stuck in a reset loop.
This check could be a separate patch
-Mathias
next prev parent reply other threads:[~2022-01-17 12:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-29 11:25 Puma Hsu
2022-01-11 11:43 ` Greg KH
2022-01-13 7:54 ` Puma Hsu
2022-01-13 8:21 ` Greg KH
2022-01-17 5:24 ` Puma Hsu
2022-01-17 12:22 ` Mathias Nyman [this message]
2022-01-18 6:50 ` Puma Hsu
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=fe411488-c67c-62ab-4709-98621b9f199b@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=albertccwang@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=pumahsu@google.com \
--cc=s.shtylyov@omp.ru \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®