mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Dayu Jiang <jiangdayu@xiaomi.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Longfang Liu <liulongfang@huawei.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	yudongbin <yudongbin@xiaomi.com>, guhuinan <guhuinan@xiaomi.com>,
	chenyu45 <chenyu45@xiaomi.com>,
	mahongwei3 <mahongwei3@xiaomi.com>
Subject: Re: [PATCH] usb: xhci: add xhci_halt() for HCE Handling
Date: Sat, 28 Feb 2026 00:22:31 +0000	[thread overview]
Message-ID: <20260228002228.5ndgx46h62pe4sau@synopsys.com> (raw)
In-Reply-To: <aaFHKC2XyqjTwbF0@oa-jiangdayu.localdomain>

On Fri, Feb 27, 2026, Dayu Jiang wrote:
> On Thu, Feb 26, 2026 at 06:17:23PM +0000, Thinh Nguyen wrote:
> > On Thu, Feb 26, 2026, Mathias Nyman wrote:
> > > On 2/26/26 11:27, Dayu Jiang wrote:
> > > > Hi Greg,
> > > > 
> > > > I have updated the changelog text as requested and resubmitted the patch.
> > > > https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/20260128100746.561626-1-jiangdayu@xiaomi.com/__;!!A4F2R9G_pg!ZSJNDKyOinm26qngopLW-axiQtwDAMely4bDqtqYDGv1ErWCtS6kZ6ZamdiKoZKuCyCk0IxMQK5g625GEIxYWFzKpAEiCUq7$
> > > > Please kindly review it and let me know if it is acceptable now.
> > > 
> > > I'll send it forward, but changed the commit message.
> > > Does this modified version still describe the case accurately:
> > > 
> > > usb: xhci: Prevent interrupt storm on host controller error (HCE)
> > > 
> > > The xHCI controller reports a Host Controller Error (HCE) in UAS Storage
> > > Device plug/unplug scenarios on Android devices, which is checked in
> > > xhci_irq() function and causes an interrupt storm (since the interrupt
> > > isn’t cleared), leading to severe system-level faults.
> > > 
> > > When the xHC controller reports HCE in the interrupt handler, the driver
> > > only logs a warning and assumes xHC activity will stop. The interrupt storm
> > > does however continue until driver manually disables xHC interrupt and
> > > stops the controller by calling xhci_halt().
> > > 
> > > The change is made in xhci_irq() function where STS_HCE status is
> > > checked, mirroring the existing error handling pattern used for
> > > STS_FATAL errors.
> > > 
> > > This only fixes the interrupt storm. Proper HCE recovery requires resetting
> > > and re-initializing the xHC.
> > > 
> > 
> > The controller is halted if there's an error like HCE. It's odd to try
> > to "halt" it again. Not sure how this will impact for other controllers.
> > Even if we don't have the full HCE recovery implemented, did we try to
> > just do HCRST, which is the first step of the recovery?
> A full recovery will not be implemented here. Performing only HCRST without 
> a proper recovery procedure may introduce unpredictable risks.

What risks?

> In the xHCI driver flow, the standard handling for exceptions is mainly 
> done via xhci_died() or xhci_halt() (please refer to the existing handling 
> flow for HSE as a reference).
> When an HCE occurs, the controller is already halted, but the interrupts 
> have not been cleared. It has been confirmed that calling xhci_halt() at this 
> point can properly resolve the interrupt storm issue.

As I noted in Mathias's reply, I'm OK with this change while waiting for
the proper handling of HCE to be implemented.

BR,
Thinh

  reply	other threads:[~2026-02-28  0:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 11:04 jiangdayu
2026-01-27 11:22 ` Greg Kroah-Hartman
2026-01-28  8:48   ` Dayu Jiang
2026-01-28  8:56     ` Greg Kroah-Hartman
2026-02-26  9:27       ` Dayu Jiang
2026-02-26 16:44         ` Mathias Nyman
2026-02-26 18:17           ` Thinh Nguyen
2026-02-27  7:26             ` Dayu Jiang
2026-02-28  0:22               ` Thinh Nguyen [this message]
2026-02-27  9:43             ` Mathias Nyman
2026-02-27 11:05               ` Michal Pecio
2026-02-28  0:06                 ` Thinh Nguyen
2026-02-28  0:18               ` Thinh Nguyen
2026-02-27  7:33           ` Dayu Jiang
2026-01-27 12:25 ` Mathias Nyman
2026-01-28  8:53   ` Dayu Jiang

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=20260228002228.5ndgx46h62pe4sau@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=chenyu45@xiaomi.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guhuinan@xiaomi.com \
    --cc=jiangdayu@xiaomi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=liulongfang@huawei.com \
    --cc=mahongwei3@xiaomi.com \
    --cc=mathias.nyman@intel.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=yudongbin@xiaomi.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®