Linux kernel -stable discussions
 help / color / mirror / Atom feed
* Re: [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership
@ 2026-09-11 15:13 McKenna Fan
  0 siblings, 0 replies; 6+ messages in thread
From: McKenna Fan @ 2026-09-11 15:13 UTC (permalink / raw)
  To: Rishabh Jain
  Cc: Mathias Nyman, Greg Kroah-Hartman, Mario Limonciello,
	Michal Pecio, Linux Usb, Linux Kernel, Stable


This is an independent test report for [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership.


I independently reproduced the problem and tested the proposed ownership behavior on a different AMD Promontory xHCI controller.

My affected controller is:

AMD B550 / Promontory-19 xHCIPCI 1022:43ee0000:02:00.0

The machine runs Manjaro and uses ACPI deep/S3 suspend.


I ended up collecting what is, frankly, an absurd amount of evidence while chasing this, including firmware analysis and repeated A/B testing, but the shortest useful version is:


Stock Manjaro 7.2.4 kernel, no helper module loaded:

EXTCAP_USBLEGSUP = 0x00000801EXTCAP_USBLEGCTLSTS = 0x40000000HC BIOS Owned = 0
HC OS Owned = 0




After entering deep S3:

xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit

After the failed resume:

EXTCAP_USBLEGSUP = 0x00000801EXTCAP_USBLEGCTLSTS = 0xc0000000

So HC OS Owned remained clear.


I then booted a custom build of the same Manjaro 7.2.4 kernel implementing the proposed behavior of asserting HC OS Owned in the xHCI handoff path. No ownership helper module was loaded.


Before S3:

EXTCAP_USBLEGSUP = 0x01000801EXTCAP_USBLEGCTLSTS = 0x40000000

HC BIOS Owned = 0

HC OS Owned = 1




I performed five consecutive deep-S3 suspend/resume cycles, including one approximately four-minute S3 residency.


All five resumed without:

xHC error in resumeUSBSTS 0x401Reinit

After the final resume:

EXTCAP_USBLEGSUP = 0x01000801EXTCAP_USBLEGCTLSTS = 0xc0000000

HC OS Owned remained asserted.


I then immediately rebooted back into the otherwise matching unmodified Manjaro 7.2.4 kernel. With no helper loaded, USBLEGSUP returned to 0x00000801, and the very first deep-S3 cycle reproduced:

xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit

This also agrees with earlier reversible testing using a very small test module which changed only HC OS Owned in USBLEGSUP:

0x00000801 -> 0x01000801

It did not reset or unbind the controller, clear USBLEGCTLSTS, or make other xHCI MMIO changes. With OS Owned asserted, repeated S3 resumes succeeded; clearing OS Owned again caused the resume failure to return.


So on this 1022:43ee controller I can independently reproduce the same causal relationship:

OS Owned clear    -> USBSTS 0x401 / controller reinitOS Owned asserted -> clean S3 resumeOS Owned clear    -> failure returnskernel asserts it -> 5/5 clean resumesstock kernel      -> first S3 fails again

One potentially useful detail is that USBLEGCTLSTS changed from 0x40000000 to 0xc0000000 after resume in both the successful and failed cases. That status change therefore does not distinguish the two outcomes here; HC OS Owned does.


This appears to extend the observed problem beyond the 1022:43fc controller in the original report to at least the related 1022:43ee Promontory controller.


I have complete logs from the positive and negative-control boots and can provide the longer A/B history or firmware findings if useful.


AI assistance disclosure: ChatGPT 5.6 Sol and Astra-medium were used during the investigation for source/code analysis, experimental planning, log comparison, and assistance preparing this report. All commands, kernel builds, suspend/resume experiments, register reads, and reported results were executed and verified on the physical system by me.


P.S. If Rishabh happens to enjoy following journalctl warnings farther than is probably reasonable, I have another USB rabbit hole which may be of interest: a kernel.org Bugzilla report on a USB3 Type-C peer-collision / port-power-management warning. The useful part is comment #1, where the issue gets reframed after more investigation:


https://bugzilla.kernel.org/show_bug.cgi?id=221987#c1


Different bug, but another fairly innocent-looking USB warning that turned out to have considerably more behind it than expected.

--
Secured with Tuta Mail:
https://tuta.com/free-email

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH v4] usb: pci-quirks: always assert xHCI OS ownership
@ 2026-09-02  3:26 Michal Pecio
  2026-09-02  5:39 ` [PATCH v5] " Rishabh Jain
  0 siblings, 1 reply; 6+ messages in thread
From: Michal Pecio @ 2026-09-02  3:26 UTC (permalink / raw)
  To: Rishabh Jain
  Cc: Mathias Nyman, Greg Kroah-Hartman, Mario Limonciello, linux-usb,
	linux-kernel, stable

On Tue, 01 Sep 2026 18:24:07 -0700, Rishabh Jain wrote:
> The xHCI ownership protocol requires the OS driver to assert the HC OS
> Owned semaphore before using the host controller, then wait for HC BIOS
> Owned to clear if firmware owns it.
> 
> quirk_usb_handoff_xhci() currently asserts OS Owned only when BIOS Owned
> is already set. If firmware leaves BIOS Owned clear, Linux uses the xHC
> while both ownership semaphores remain clear.
> 
> On an AMD PROM21 xHCI controller (1022:43fc), this caused every S3
> resume to terminate Controller Restore State with USBSTS 0x401. Linux
> then reset the host controller, both root hubs and the USB Bluetooth
> adapter.
> 
> The controller entered resume ready and halted with USBSTS 0x1.
> Endpoint state, 100 ms save/restore delays, scratchpads, the DCBAA,
> device contexts and command, event and transfer rings were verified not
> to cause the restore error.
> 
> Across four S3 cycles, asserting only HC OS Owned changed USBLEGSUP from
> 0x00000801 to 0x01000801 and eliminated the restore failure. Testing
> included the unmodified 7.1.8-ogc1.1.fc44.x86_64 distribution kernel
> using a test module that set the HC OS Owned semaphore. Clearing
> USBLEGCTLSTS was independently verified to be unnecessary.
> 
> Always assert OS Owned for controllers using the standard xHCI handoff,
> and leave the existing TI/Renesas forced handoff unchanged. Keep OS
> Owned asserted after the standard handoff to prevent firmware from
> reclaiming the controller during subsequent suspends.
> 
> Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
> ---
> Thanks for the review.
> 
> By "stock-kernel test", I meant that the register change was tested on
> the unmodified 7.1.8-ogc1.1.fc44.x86_64 distribution kernel using a test
> module that set the HC OS Owned semaphore.
> 
> Sorry, I missed the AI assistant guidelines. Fixed now.
> 
> The TI/Renesas forced-handoff path is restored unchanged. This revision
> only changes the standard handoff path. I left the byte-access change
> out of this patch.
> 
> Changes in v4:
> - Preserve the existing TI/Renesas forced-handoff path.
> - Limit the ownership change to the standard handoff path.
> 
>  drivers/usb/host/pci-quirks.c | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 0404489c2f6a..fa9b5db4d115 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -1193,22 +1193,25 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>  			 && pdev->device == 0x0014)) {
>  		val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
>  		writel(val, base + ext_cap_offset);
> -	}
> -
> -	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
> -	if (val & XHCI_HC_BIOS_OWNED) {
> -		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
> +	} else {
> +		/*
> +		 * Perform the standard handoff and leave OS ownership set to
> +		 * keep the BIOS at bay during subsequent suspends.
> +		 */
> +		val |= XHCI_HC_OS_OWNED;
> +		writel(val, base + ext_cap_offset);

The change from val|OS_OWNED to val|=OS_OWNED doesn't seem necessary.

>  
>  		/* Wait for 1 second with 10 microsecond polling interval */
>  		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
> -				0, 1000000, 10);
> +				    0, 1000000, 10);

And this whitespace tweak isn't either.

>  
>  		/* Assume a buggy BIOS and take HC ownership anyway */
>  		if (timeout) {
>  			dev_warn(&pdev->dev,
>  				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
>  				 val);

Note that val is being logged here in case of error. It's probably
better to preserve the original value for this purpose. We *know* that
the code above tried to add OS_OWNED, but we don't know whether it was
set before or not. Not sure if we will ever want to know, but still...

> -			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
> +			writel(val & ~XHCI_HC_BIOS_OWNED,
> +			       base + ext_cap_offset);

OK, I see, this could unintentionally clear OS Owned together with BIOS
Owned. This can be prevented by explicitly oring OS Owned here. And it
would make sense to document this problem in the commit message if you
are trying to solve it in this patch.

Other than that, I think this looks good. Just in caes, pease test the
final version once more to ensure we haven't broken something.

>  		}
>  	}
>  
> -- 
> 2.50.1 (Apple Git-155)
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-10-30 16:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-11 15:13 [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership McKenna Fan
  -- strict thread matches above, loose matches on Subject: below --
2026-09-02  3:26 [PATCH v4] " Michal Pecio
2026-09-02  5:39 ` [PATCH v5] " Rishabh Jain
2026-10-12 20:14   ` Mario Limonciello
2026-10-15  9:17     ` Michal Pecio
2026-10-15 13:01       ` Mario Limonciello
2026-10-30 16:52   ` Maciej Zonski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox