mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Wen Xiong <wenxiong@linux.ibm.com>
Cc: mathias.nyman@intel.com, gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, wenxiong@us.ibm.com,
	Brian King <brking@linux.vnet.ibm.com>,
	Samuel Mendoza-Jonas <sam@mendozajonas.com>,
	Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH] xhci: Reset controller on xhci shutdown
Date: Wed, 21 Oct 2026 11:27:05 +0200	[thread overview]
Message-ID: <20261021112705.19fd90b8.michal.pecio@gmail.com> (raw)
In-Reply-To: <5510281a5d91bbd435d9920431a3fa75@linux.ibm.com>

On Tue, 20 Oct 2026 15:40:24 -0500, Wen Xiong wrote:
> Above patch is similar like my V1 patch.
> It works fine and all usb devices are showed up after executing a kexec.

Thanks for testing. The big difference is that my patch does nothing
if the preceding xhci_halt() completes successfully. So if it helps,
this tells us that xhci_halt() fails and the chip most likely locks up
right there, during xhci_shutdown().

It probably fails due to some devices that are connected and haven't 
been shut down normally; I suspect that nothing bad would happen if
you disconnect all devices or unbind xhci_hcd before kexec, but we
still need to cope with surprise shutdown somehow.

In such case your suggestion to PCI reset may be the simplest way out.
It seems we could either call it always on TI chips, or automatically
as a fallback when xhci_shutdown() fails to halt the xHC.

Mathias, any preferences?

The latter is perhaps a bit cleaner and more generally useful, though
I must say that I tested rebooting with a bunch of devices connected
to a few different HCs and all of them passed through xhci_shutdown()
successfully, so the issue isn't widespread. I don't have TUSB7340.

Regards,
Michal

      reply	other threads:[~2026-10-21  9:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 22:25 wenxiong
2026-10-01 22:40 ` Mathias Nyman
2026-10-02 14:08   ` Wen Xiong
2026-10-02  8:29 ` Michal Pecio
2026-10-02 14:05   ` Wen Xiong
2026-10-02 14:18     ` Michal Pecio
2026-10-05 13:01       ` Wen Xiong
2026-10-06 10:55         ` Michal Pecio
2026-10-14 20:32           ` Wen Xiong
2026-10-15  8:33             ` Michal Pecio
2026-10-20 20:40               ` Wen Xiong
2026-10-21  9:27                 ` Michal Pecio [this message]

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=20261021112705.19fd90b8.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel@jms.id.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=sam@mendozajonas.com \
    --cc=stable@vger.kernel.org \
    --cc=wenxiong@linux.ibm.com \
    --cc=wenxiong@us.ibm.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

all inboxes | Powered by JetHome®