[PATCH] usb: pci-quirks: always assert xHCI OS ownership

[PATCH] usb: pci-quirks: always assert xHCI OS ownership

[Rishabh Jain]

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.

Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
0x01000801 and eliminated the restore failure across four S3 cycles,
including a stock-kernel test. Clearing USBLEGCTLSTS was independently
verified to be unnecessary.

Always assert OS Owned when the xHCI Legacy Support capability is
present. Use the independently accessible ownership byte so firmware
can update BIOS Owned without racing a 32-bit read-modify-write. Keep
the existing BIOS handoff wait and legacy SMI cleanup unchanged.

Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
Tested-by: Rishabh Jain <rishabh.jain1198@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
---
Additional context:

* Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
  behavior and its impact on attached USB devices:
  https://bugzilla.kernel.org/show_bug.cgi?id=216470

* Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
  xHC") is related workaround history: it tolerates a distinct AMD CSS
  timeout and resets the controller on resume:
  https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d

The external reports do not record their ownership semaphore values but
are included as corroborating failure signatures that this might fix.

drivers/usb/host/pci-quirks.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 0404489c2f6a..d76a4791b8f5 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1185,6 +1185,14 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 		dev_warn(&pdev->dev, "xHCI controller failing to respond");
 		goto iounmap;
 	}
+
+	/*
+	 * The OS ownership semaphore must be asserted while the OS owns the
+	 * xHC, even if firmware did not assert the BIOS ownership semaphore.
+	 * Update only the OS ownership byte to avoid racing with firmware.
+	 */
+	writeb(readb(base + ext_cap_offset + 3) | BIT(0),
+	       base + ext_cap_offset + 3);
 	val = readl(base + ext_cap_offset);
 
 	/* Auto handoff never worked for these devices. Force it and continue */
@@ -1195,10 +1203,8 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 		writel(val, base + ext_cap_offset);
 	}
 
-	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
+	/* If the BIOS owns the HC, wait for it to hand over control */
 	if (val & XHCI_HC_BIOS_OWNED) {
-		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
-
 		/* Wait for 1 second with 10 microsecond polling interval */
 		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
 				0, 1000000, 10);
-- 
2.50.1 (Apple Git-155)

Re: [PATCH] usb: pci-quirks: always assert xHCI OS ownership

[Mario Limonciello]

On 8/14/26 20:45, 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.
> 
> Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
> 0x01000801 and eliminated the restore failure across four S3 cycles,
> including a stock-kernel test. Clearing USBLEGCTLSTS was independently
> verified to be unnecessary.
> 
> Always assert OS Owned when the xHCI Legacy Support capability is
> present. Use the independently accessible ownership byte so firmware
> can update BIOS Owned without racing a 32-bit read-modify-write. Keep
> the existing BIOS handoff wait and legacy SMI cleanup unchanged.
> 
> Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
> Tested-by: Rishabh Jain <rishabh.jain1198@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
> ---
> Additional context:
> 
> * Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
>    behavior and its impact on attached USB devices:
>    https://bugzilla.kernel.org/show_bug.cgi?id=216470
> 
> * Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
>    xHC") is related workaround history: it tolerates a distinct AMD CSS
>    timeout and resets the controller on resume:
>    https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d
> 
> The external reports do not record their ownership semaphore values but
> are included as corroborating failure signatures that this might fix.
> 
> drivers/usb/host/pci-quirks.c | 12 +++++++++---
>   1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 0404489c2f6a..d76a4791b8f5 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -1185,6 +1185,14 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   		dev_warn(&pdev->dev, "xHCI controller failing to respond");
>   		goto iounmap;
>   	}
> +
> +	/*
> +	 * The OS ownership semaphore must be asserted while the OS owns the
> +	 * xHC, even if firmware did not assert the BIOS ownership semaphore.
> +	 * Update only the OS ownership byte to avoid racing with firmware.
> +	 */
> +	writeb(readb(base + ext_cap_offset + 3) | BIT(0),
> +	       base + ext_cap_offset + 3);

I'm assuming you are actually meaning XHCI_EXT_CAPS_PM for the 3 here. 
Why are you doing all this math?

We already have the defines XHCI_HC_OS_OWNED, can't you just use that?

And for that matter it sounds like you are really proposing to just 
remove this check but adding more complexity in the process.

	if (val & XHCI_HC_BIOS_OWNED)

I guess the way I would do this is at least leave a debug breadcrumb 
since you're reading the register something like this:

val = readl(base + ext_cap_offset);
if (val & XHCI_HC_BIOS_OWNED)
	pci_debug(pdev, "BIOS owns XHCI HC\n"0;
writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
timeout = handshake(...)
if (timeout && (val & XHCI_HC_BIOS_OWNED)) {
	dev_warn(...)
	writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
}

Then you have a single read, no extra writes.

>   	val = readl(base + ext_cap_offset);
>   
>   	/* Auto handoff never worked for these devices. Force it and continue */
> @@ -1195,10 +1203,8 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   		writel(val, base + ext_cap_offset);
>   	}
>   
> -	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
> +	/* If the BIOS owns the HC, wait for it to hand over control */
>   	if (val & XHCI_HC_BIOS_OWNED) {
> -		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
> -
>   		/* Wait for 1 second with 10 microsecond polling interval */
>   		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
>   				0, 1000000, 10);

[PATCH v2] usb: pci-quirks: always assert xHCI OS ownership

[Rishabh Jain]

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.

Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
0x01000801 and eliminated the restore failure across four S3 cycles,
including a stock-kernel test. Clearing USBLEGCTLSTS was independently
verified to be unnecessary.

Always assert OS Owned when the xHCI Legacy Support capability is
present. Use the existing ownership masks with a single initial register
read/write, and leave a debug breadcrumb when firmware owns the
controller. Keep the existing BIOS handoff recovery and legacy SMI
cleanup unchanged.

Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
Tested-by: Rishabh Jain <rishabh.jain1198@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
---
Ah, agreed, I didn't see XHCI_HC_OS_OWNED is defined! The +3 in v1 was
for selecting byte 3 of USBLEGSUP.

I've simplified v2 to use the existing ownership masks, one initial
read/write (makes sense to batch the writes), and the debug breadcrumb
you suggested.

Changes in v2:
- Use XHCI_HC_OS_OWNED instead of byte-offset access.
- Fold the TI/Renesas forced handoff into the ownership-register write.
- Add a debug breadcrumb when BIOS ownership is initially set.
- Make the BIOS handoff wait unconditional and gate recovery on the initial
  BIOS ownership state.

Additional context:

* Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
  behavior and its impact on attached USB devices:
  https://bugzilla.kernel.org/show_bug.cgi?id=216470

* Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
  xHC") is related workaround history: it tolerates a distinct AMD CSS
  timeout and resets the controller on resume:
  https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d

The external reports do not record their ownership semaphore values but
are included as corroborating failure signatures that this might fix.

 drivers/usb/host/pci-quirks.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 0404489c2f6a..29e635a036a6 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1185,31 +1185,31 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 		dev_warn(&pdev->dev, "xHCI controller failing to respond");
 		goto iounmap;
 	}
+
 	val = readl(base + ext_cap_offset);
+	if (val & XHCI_HC_BIOS_OWNED)
+		pci_dbg(pdev, "BIOS owns xHCI HC\n");
 
 	/* Auto handoff never worked for these devices. Force it and continue */
 	if ((pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) ||
 			(pdev->vendor == PCI_VENDOR_ID_RENESAS
 			 && pdev->device == 0x0014)) {
-		val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
-		writel(val, base + ext_cap_offset);
+		val &= ~XHCI_HC_BIOS_OWNED;
 	}
 
-	/* 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);
+	val |= XHCI_HC_OS_OWNED;
+	writel(val, base + ext_cap_offset);
 
-		/* Wait for 1 second with 10 microsecond polling interval */
-		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
-				0, 1000000, 10);
+	/* Wait for 1 second with 10 microsecond polling interval */
+	timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
+			    0, 1000000, 10);
 
-		/* Assume a buggy BIOS and take HC ownership anyway */
-		if (timeout) {
-			dev_warn(&pdev->dev,
-				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
-				 val);
-			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
-		}
+	/* Assume a buggy BIOS and take HC ownership anyway */
+	if (timeout && (val & XHCI_HC_BIOS_OWNED)) {
+		dev_warn(&pdev->dev,
+			 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
+			 val);
+		writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
 	}
 
 	val = readl(base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v2] usb: pci-quirks: always assert xHCI OS ownership

[Greg Kroah-Hartman]

On Sun, Aug 16, 2026 at 11:15:19AM -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.
> 
> Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
> 0x01000801 and eliminated the restore failure across four S3 cycles,
> including a stock-kernel test. Clearing USBLEGCTLSTS was independently
> verified to be unnecessary.
> 
> Always assert OS Owned when the xHCI Legacy Support capability is
> present. Use the existing ownership masks with a single initial register
> read/write, and leave a debug breadcrumb when firmware owns the
> controller. Keep the existing BIOS handoff recovery and legacy SMI
> cleanup unchanged.
> 
> Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
> Tested-by: Rishabh Jain <rishabh.jain1198@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>

Tested-by: is implied if you sign off on a patch, no need to include it.



> ---
> Ah, agreed, I didn't see XHCI_HC_OS_OWNED is defined! The +3 in v1 was
> for selecting byte 3 of USBLEGSUP.
> 
> I've simplified v2 to use the existing ownership masks, one initial
> read/write (makes sense to batch the writes), and the debug breadcrumb
> you suggested.
> 
> Changes in v2:
> - Use XHCI_HC_OS_OWNED instead of byte-offset access.
> - Fold the TI/Renesas forced handoff into the ownership-register write.
> - Add a debug breadcrumb when BIOS ownership is initially set.
> - Make the BIOS handoff wait unconditional and gate recovery on the initial
>   BIOS ownership state.
> 
> Additional context:
> 
> * Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
>   behavior and its impact on attached USB devices:
>   https://bugzilla.kernel.org/show_bug.cgi?id=216470
> 
> * Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
>   xHC") is related workaround history: it tolerates a distinct AMD CSS
>   timeout and resets the controller on resume:
>   https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d
> 
> The external reports do not record their ownership semaphore values but
> are included as corroborating failure signatures that this might fix.
> 
>  drivers/usb/host/pci-quirks.c | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 0404489c2f6a..29e635a036a6 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -1185,31 +1185,31 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>  		dev_warn(&pdev->dev, "xHCI controller failing to respond");
>  		goto iounmap;
>  	}
> +
>  	val = readl(base + ext_cap_offset);
> +	if (val & XHCI_HC_BIOS_OWNED)
> +		pci_dbg(pdev, "BIOS owns xHCI HC\n");

Who needs this new message?

thanks,

greg k-h

[PATCH v3] usb: pci-quirks: always assert xHCI OS ownership

[Rishabh Jain]

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.

Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
0x01000801 and eliminated the restore failure across four S3 cycles,
including a stock-kernel test. Clearing USBLEGCTLSTS was independently
verified to be unnecessary.

Always assert OS Owned when the xHCI Legacy Support capability is
present. Use the existing ownership masks with a single initial register
read/write. Keep the existing BIOS handoff recovery and legacy SMI
cleanup unchanged.

Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
Cc: stable@vger.kernel.org
Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
---
Changes in v3:
- Drop the unnecessary BIOS ownership debug message.
- Drop the redundant self Tested-by tag.

Changes in v2:
- Use XHCI_HC_OS_OWNED instead of byte-offset access.
- Fold the TI/Renesas forced handoff into the ownership-register write.
- Make the BIOS handoff wait unconditional and gate recovery on the initial
  BIOS ownership state.

Additional context:

* Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
  behavior and its impact on attached USB devices:
  https://bugzilla.kernel.org/show_bug.cgi?id=216470

* Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
  xHC") is related workaround history: it tolerates a distinct AMD CSS
  timeout and resets the controller on resume:
  https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d

The external reports do not record their ownership semaphore values but
are included as corroborating failure signatures that this might fix.

 drivers/usb/host/pci-quirks.c | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 0404489c2f6a9..52d41ac5daa85 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1191,25 +1191,22 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 	if ((pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) ||
 			(pdev->vendor == PCI_VENDOR_ID_RENESAS
 			 && pdev->device == 0x0014)) {
-		val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
-		writel(val, base + ext_cap_offset);
+		val &= ~XHCI_HC_BIOS_OWNED;
 	}
 
-	/* 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);
+	val |= XHCI_HC_OS_OWNED;
+	writel(val, base + ext_cap_offset);
 
-		/* Wait for 1 second with 10 microsecond polling interval */
-		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
-				0, 1000000, 10);
+	/* Wait for 1 second with 10 microsecond polling interval */
+	timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
+			    0, 1000000, 10);
 
-		/* Assume a buggy BIOS and take HC ownership anyway */
-		if (timeout) {
-			dev_warn(&pdev->dev,
-				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
-				 val);
-			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
-		}
+	/* Assume a buggy BIOS and take HC ownership anyway */
+	if (timeout && (val & XHCI_HC_BIOS_OWNED)) {
+		dev_warn(&pdev->dev,
+			 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
+			 val);
+		writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
 	}
 
 	val = readl(base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v3] usb: pci-quirks: always assert xHCI OS ownership

[Mario Limonciello]

On 8/31/26 16:11, 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.
> 
> Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
> 0x01000801 and eliminated the restore failure across four S3 cycles,
> including a stock-kernel test. Clearing USBLEGCTLSTS was independently
> verified to be unnecessary.
> 
> Always assert OS Owned when the xHCI Legacy Support capability is
> present. Use the existing ownership masks with a single initial register
> read/write. Keep the existing BIOS handoff recovery and legacy SMI
> cleanup unchanged.
> 
> Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>> ---
> Changes in v3:
> - Drop the unnecessary BIOS ownership debug message.
> - Drop the redundant self Tested-by tag.
> 
> Changes in v2:
> - Use XHCI_HC_OS_OWNED instead of byte-offset access.
> - Fold the TI/Renesas forced handoff into the ownership-register write.
> - Make the BIOS handoff wait unconditional and gate recovery on the initial
>    BIOS ownership state.
> 
> Additional context:
> 
> * Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
>    behavior and its impact on attached USB devices:
>    https://bugzilla.kernel.org/show_bug.cgi?id=216470
> 
> * Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
>    xHC") is related workaround history: it tolerates a distinct AMD CSS
>    timeout and resets the controller on resume:
>    https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d
> 
> The external reports do not record their ownership semaphore values but
> are included as corroborating failure signatures that this might fix.
> 
>   drivers/usb/host/pci-quirks.c | 27 ++++++++++++---------------
>   1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 0404489c2f6a9..52d41ac5daa85 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -1191,25 +1191,22 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   	if ((pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) ||
>   			(pdev->vendor == PCI_VENDOR_ID_RENESAS
>   			 && pdev->device == 0x0014)) {
> -		val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
> -		writel(val, base + ext_cap_offset);
> +		val &= ~XHCI_HC_BIOS_OWNED;
>   	}
>   
> -	/* 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);
> +	val |= XHCI_HC_OS_OWNED;
> +	writel(val, base + ext_cap_offset);
>   
> -		/* Wait for 1 second with 10 microsecond polling interval */
> -		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
> -				0, 1000000, 10);
> +	/* Wait for 1 second with 10 microsecond polling interval */
> +	timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
> +			    0, 1000000, 10);
>   
> -		/* Assume a buggy BIOS and take HC ownership anyway */
> -		if (timeout) {
> -			dev_warn(&pdev->dev,
> -				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
> -				 val);
> -			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
> -		}
> +	/* Assume a buggy BIOS and take HC ownership anyway */
> +	if (timeout && (val & XHCI_HC_BIOS_OWNED)) {
> +		dev_warn(&pdev->dev,
> +			 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
> +			 val);
> +		writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
>   	}
>   
>   	val = readl(base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);

Re: [PATCH v3] usb: pci-quirks: always assert xHCI OS ownership

[Michal Pecio]

On Mon, 31 Aug 2026 14:11:26 -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.
> 
> Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
> 0x01000801 and eliminated the restore failure across four S3 cycles,
> including a stock-kernel test. Clearing USBLEGCTLSTS was independently
> verified to be unnecessary.

Not sure what you mean by a "stock-kernel test"?

> 
> Always assert OS Owned when the xHCI Legacy Support capability is
> present. Use the existing ownership masks with a single initial register
> read/write. Keep the existing BIOS handoff recovery and legacy SMI
> cleanup unchanged.
> 
> Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>

Does this submission comply with the attribution rulese here?
https://docs.kernel.org/process/coding-assistants.html

> ---
> Changes in v3:
> - Drop the unnecessary BIOS ownership debug message.
> - Drop the redundant self Tested-by tag.
> 
> Changes in v2:
> - Use XHCI_HC_OS_OWNED instead of byte-offset access.
> - Fold the TI/Renesas forced handoff into the ownership-register write.
> - Make the BIOS handoff wait unconditional and gate recovery on the initial
>   BIOS ownership state.
> 
> Additional context:
> 
> * Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
>   behavior and its impact on attached USB devices:
>   https://bugzilla.kernel.org/show_bug.cgi?id=216470
> 
> * Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
>   xHC") is related workaround history: it tolerates a distinct AMD CSS
>   timeout and resets the controller on resume:
>   https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d
> 
> The external reports do not record their ownership semaphore values but
> are included as corroborating failure signatures that this might fix.
> 
>  drivers/usb/host/pci-quirks.c | 27 ++++++++++++---------------
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 0404489c2f6a9..52d41ac5daa85 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -1191,25 +1191,22 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>  	if ((pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) ||
>  			(pdev->vendor == PCI_VENDOR_ID_RENESAS
>  			 && pdev->device == 0x0014)) {
> -		val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
> -		writel(val, base + ext_cap_offset);
> +		val &= ~XHCI_HC_BIOS_OWNED;
>  	}

I'm not sure why touching this code has been suggested to you. You
don't have this hardware, you can't test this change, and it isn't
required for achieving your goal.

[Actually, I doubt this whole code and the (not visible here) comment
above it, because nobody had issues with uPD720200 and uPD720202, so
it's unlikely that uPD720201 is broken. Probably this was a workaround
for someone's buggy BIOS. But I'm digressing.]

A stable bugfix is a particular case where one commit should do one
thing and do it well. So it should preserve the original behavior for
"broken" chips and only affect those chips where we do actually try
to perform the handoff handshake in accordance with xHCI spec.

So this is the actual change you wanted to do:

> -	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
> -	if (val & XHCI_HC_BIOS_OWNED) {

and to preserve existing "broken chip" behavior, you could add

+ } else {
+ 	/* Perform standard handshake and leave OS_OWNED set
+        * to keep the BIOS at bay during subsequent suspends

And it seems that this is enough.

However, as v1 rightly pointed out, this code is dubious because
it performs read-modify-write on the whole DWORD, of which the
BIOS_OWNED bit may be concurrently modified by the BIOS (though it
isn't clear if that would ever happen under any circumstances).

So the change from writel() to writeb() in v1 actually made sense,
maybe as a separate patch because it's a separate change. xHCI spec
is clear that HW must support writeb() accesses to this register,
exactly for this reason, so regression risk seems low.

Regards,
Michal

[PATCH v4] usb: pci-quirks: always assert xHCI OS ownership

[Rishabh Jain]

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);
 
 		/* 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);
 
 		/* Assume a buggy BIOS and take HC ownership anyway */
 		if (timeout) {
 			dev_warn(&pdev->dev,
 				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
 				 val);
-			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
+			writel(val & ~XHCI_HC_BIOS_OWNED,
+			       base + ext_cap_offset);
 		}
 	}
 
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v4] usb: pci-quirks: always assert xHCI OS ownership

[Michal Pecio]

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)
> 

[PATCH v5] usb: pci-quirks: always assert xHCI OS ownership

[Rishabh Jain]

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.

The timeout fallback also clears BIOS Owned using the original register
value, which can clear OS Owned at the same time.

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. The same test
was repeated after review with the same result. 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, including when forcing BIOS
Owned clear after a timeout, 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>
---
I kept val unchanged for the error log, restored the original handshake
formatting, and explicitly preserve OS Owned when forcing BIOS Owned
clear after a timeout. Documented timeout issue in commit message.

I repeated the same S3 test on the unmodified
7.1.8-ogc1.1.fc44.x86_64 distribution kernel using the test module, with
the same successful result.

Changes in v5:
- Preserve the original ownership value for error logging.
- Restore the original handshake formatting.
- Explicitly retain OS Owned in the timeout fallback.

 drivers/usb/host/pci-quirks.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 0404489c2f6a..2b12a35e6f10 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1193,10 +1193,11 @@ 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) {
+	} else {
+		/*
+		 * Perform the standard handoff and leave OS ownership set to
+		 * keep the BIOS at bay during subsequent suspends.
+		 */
 		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
 
 		/* Wait for 1 second with 10 microsecond polling interval */
@@ -1208,7 +1209,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 			dev_warn(&pdev->dev,
 				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
 				 val);
-			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
+			writel((val | XHCI_HC_OS_OWNED) &
+			       ~XHCI_HC_BIOS_OWNED,
+			       base + ext_cap_offset);
 		}
 	}
 
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership

[Mario Limonciello]

On 9/2/26 00:39, 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.
> 
> The timeout fallback also clears BIOS Owned using the original register
> value, which can clear OS Owned at the same time.
> 
> 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. The same test
> was repeated after review with the same result. 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, including when forcing BIOS
> Owned clear after a timeout, 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>
> ---

Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>

> I kept val unchanged for the error log, restored the original handshake
> formatting, and explicitly preserve OS Owned when forcing BIOS Owned
> clear after a timeout. Documented timeout issue in commit message.
> 
> I repeated the same S3 test on the unmodified
> 7.1.8-ogc1.1.fc44.x86_64 distribution kernel using the test module, with
> the same successful result.
> 
> Changes in v5:
> - Preserve the original ownership value for error logging.
> - Restore the original handshake formatting.
> - Explicitly retain OS Owned in the timeout fallback.
> 
>   drivers/usb/host/pci-quirks.c | 13 ++++++++-----
>   1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 0404489c2f6a..2b12a35e6f10 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -1193,10 +1193,11 @@ 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) {
> +	} else {
> +		/*
> +		 * Perform the standard handoff and leave OS ownership set to
> +		 * keep the BIOS at bay during subsequent suspends.
> +		 */
>   		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
>   
>   		/* Wait for 1 second with 10 microsecond polling interval */
> @@ -1208,7 +1209,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   			dev_warn(&pdev->dev,
>   				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
>   				 val);
> -			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
> +			writel((val | XHCI_HC_OS_OWNED) &
> +			       ~XHCI_HC_BIOS_OWNED,
> +			       base + ext_cap_offset);
>   		}
>   	}
>   

Re: [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership

[Michal Pecio]

On Mon, 12 Oct 2026 15:14:14 -0500, Mario Limonciello wrote:
> On 9/2/26 00:39, 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.
> > 
> > The timeout fallback also clears BIOS Owned using the original register
> > value, which can clear OS Owned at the same time.
> > 
> > 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. The same test
> > was repeated after review with the same result. 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, including when forcing BIOS
> > Owned clear after a timeout, 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>
> > ---  
> 
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>

Yes, this fixes a legit issue and would be worth getting in mainline.
Two users confirmed the patch works for them, though no one could be
bothered to post proper Tested-by here :(

https://lore.kernel.org/linux-usb/P1FsfbW--F-9@tuta.io/
https://lore.kernel.org/linux-usb/CY8PR14MB59803EC0F6C7FD39A6D3C42FA0BF2@CY8PR14MB5980.namprd14.prod.outlook.com/

> 
> > I kept val unchanged for the error log, restored the original handshake
> > formatting, and explicitly preserve OS Owned when forcing BIOS Owned
> > clear after a timeout. Documented timeout issue in commit message.
> > 
> > I repeated the same S3 test on the unmodified
> > 7.1.8-ogc1.1.fc44.x86_64 distribution kernel using the test module, with
> > the same successful result.
> > 
> > Changes in v5:
> > - Preserve the original ownership value for error logging.
> > - Restore the original handshake formatting.
> > - Explicitly retain OS Owned in the timeout fallback.
> > 
> >   drivers/usb/host/pci-quirks.c | 13 ++++++++-----
> >   1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > index 0404489c2f6a..2b12a35e6f10 100644
> > --- a/drivers/usb/host/pci-quirks.c
> > +++ b/drivers/usb/host/pci-quirks.c
> > @@ -1193,10 +1193,11 @@ 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) {
> > +	} else {
> > +		/*
> > +		 * Perform the standard handoff and leave OS ownership set to
> > +		 * keep the BIOS at bay during subsequent suspends.
> > +		 */
> >   		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
> >   
> >   		/* Wait for 1 second with 10 microsecond polling interval */
> > @@ -1208,7 +1209,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
> >   			dev_warn(&pdev->dev,
> >   				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
> >   				 val);
> > -			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
> > +			writel((val | XHCI_HC_OS_OWNED) &
> > +			       ~XHCI_HC_BIOS_OWNED,
> > +			       base + ext_cap_offset);
> >   		}
> >   	}
> >     
> 

Re: [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership

[Mario Limonciello]

On 10/15/26 04:17, Michal Pecio wrote:
> On Mon, 12 Oct 2026 15:14:14 -0500, Mario Limonciello wrote:
>> On 9/2/26 00:39, 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.
>>>
>>> The timeout fallback also clears BIOS Owned using the original register
>>> value, which can clear OS Owned at the same time.
>>>
>>> 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. The same test
>>> was repeated after review with the same result. 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, including when forcing BIOS
>>> Owned clear after a timeout, 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>
>>> ---
>>
>> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> 
> Yes, this fixes a legit issue and would be worth getting in mainline.
> Two users confirmed the patch works for them, though no one could be
> bothered to post proper Tested-by here :(
> 
> https://lore.kernel.org/linux-usb/P1FsfbW--F-9@tuta.io/
> https://lore.kernel.org/linux-usb/CY8PR14MB59803EC0F6C7FD39A6D3C42FA0BF2@CY8PR14MB5980.namprd14.prod.outlook.com/

They're public assertions, let's just put T-b tags for them so b4 can 
pick them up from this thread.

Tested-by: McKenna Fan <blue_sun@tuta.io>
Tested-by: Quinn Schive <quinnschive@hotmail.com>
> 
>>
>>> I kept val unchanged for the error log, restored the original handshake
>>> formatting, and explicitly preserve OS Owned when forcing BIOS Owned
>>> clear after a timeout. Documented timeout issue in commit message.
>>>
>>> I repeated the same S3 test on the unmodified
>>> 7.1.8-ogc1.1.fc44.x86_64 distribution kernel using the test module, with
>>> the same successful result.
>>>
>>> Changes in v5:
>>> - Preserve the original ownership value for error logging.
>>> - Restore the original handshake formatting.
>>> - Explicitly retain OS Owned in the timeout fallback.
>>>
>>>    drivers/usb/host/pci-quirks.c | 13 ++++++++-----
>>>    1 file changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
>>> index 0404489c2f6a..2b12a35e6f10 100644
>>> --- a/drivers/usb/host/pci-quirks.c
>>> +++ b/drivers/usb/host/pci-quirks.c
>>> @@ -1193,10 +1193,11 @@ 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) {
>>> +	} else {
>>> +		/*
>>> +		 * Perform the standard handoff and leave OS ownership set to
>>> +		 * keep the BIOS at bay during subsequent suspends.
>>> +		 */
>>>    		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
>>>    
>>>    		/* Wait for 1 second with 10 microsecond polling interval */
>>> @@ -1208,7 +1209,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>>>    			dev_warn(&pdev->dev,
>>>    				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
>>>    				 val);
>>> -			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
>>> +			writel((val | XHCI_HC_OS_OWNED) &
>>> +			       ~XHCI_HC_BIOS_OWNED,
>>> +			       base + ext_cap_offset);
>>>    		}
>>>    	}
>>>      
>>

Re: [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership

[Bruno Filipe]

Hi Rishabh,

I tested v5 on an ASRock X670E Taichi (Ryzen 9 7950X,
BIOS 4.43) with two AMD xHCI controllers (1022:43f7).

Previously, both controllers consistently reported USBSTS
0x401 on S3 resume. With v5 applied to 7.2.11-1-cachyos,
neither controller reported this error across four
consecutive S3 cycles.

Resume also feels noticeably smoother.

Tested-by: Bruno Filipe <bmilreu@gmail.com>

Re: [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership

[Maciej Zonski]

Hi,

I tested v5 of this patch on an ASUS ROG STRIX X870-I GAMING WIFI
(AMD 800 series chipset). It fixes the failed xHCI state restore on S3
resume and no USB device is reset any more.

Tested-by: Maciej Zonski <me@zonni.pl>

Hardware
--------
  Board:   ASUS ROG STRIX X870-I GAMING WIFI, BIOS 1805 (09/18/2026)
  CPU:     AMD Ryzen 9 9950X3D
  Sleep:   S3 ("deep"); /sys/power/mem_sleep is "s2idle [deep]"

  6f:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
          800 Series Chipset USB 3.x XHCI Controller [1022:43fc] (rev 01)
          driver: xhci-pci-prom21
          path:   00:02.1 -> 03:00.0 -> 04:0c.0 -> 6f:00.0
                  (behind the chipset PCIe switch)

  Devices on that controller: Intel AX210 Bluetooth (8087:0032), a
  Logitech Logi Bolt receiver (046d:c548), a YubiKey, and several
  HID devices.

  The CPU xHCI controllers (72:00.3, 72:00.4, 73:00.0) and the ASMedia
  ASM4242 controller (6b:00.0) resume fine with and without the patch.
  Only 6f:00.0 is affected.

Kernel
------
  7.2.8 (NixOS, CachyOS flavour, so v7.2.8 plus the CachyOS patch set).
  v5 applied cleanly (drivers/usb/host/pci-quirks.c only).

Before the patch
----------------
Every S3 resume I looked at showed this (shortened):

  xhci-pci-prom21 0000:6f:00.0: xHC error in resume, USBSTS 0x401, Reinit
  usb usb8: root hub lost power or was reset
  usb usb9: root hub lost power or was reset
  usb 8-7: WARN: invalid context state for evaluate context command.
  usb 8-8: reset full-speed USB device number 6 using xhci-pci-prom21
  usb 8-4: reset high-speed USB device number 2 using xhci-pci-prom21
  usb 8-11: reset high-speed USB device number 7 using xhci-pci-prom21
  usb 8-7: reset full-speed USB device number 5 using xhci-pci-prom21
  usb 8-6: reset full-speed USB device number 4 using xhci-pci-prom21
  usb 8-5: USB disconnect, device number 10
  Bluetooth: hci0: Found device firmware: intel/ibt-0041-0041.sfi

USBSTS 0x401 is HCH | SRE (halted, save/restore error). btusb then
re-probed the AX210, so bluetoothd lost and re-created the adapter, and
the USB devices on that controller were reset or re-enumerated.

The disconnect was also visible: on every resume the desktop showed a
"YubiKey connected" notification, because the key was re-enumerated as
a new device (device number 10 -> 11 in the log).

With v5 applied
---------------
I analyzed three S3 suspend/resume cycles on the patched kernel:

  - two short ones in a row on one boot (about 13 s asleep each),
  - one long one on a later boot: 07:29:58 -> 16:19:29, about 8 h 49 min
    asleep.

In all three, the kernel log between "PM: suspend entry (deep)" and
"PM: suspend exit" contains none of the lines above: no "xHC error in
resume", no "root hub lost power or was reset", no "reset ... USB
device", no USB disconnect, and no hci0 firmware/probe lines. The
Bluetooth adapter stayed bound to btusb, and the YubiKey and the AX210
were still enumerated after the long sleep.

The "YubiKey connected" notification that appeared after every resume
before the patch has not appeared since the patch was applied.

The patch also fixed a problem I had given up on: my Logitech Bolt
receiver (046d:c548, port 8-6 on this controller) was reset and
re-enumerated on every resume, which made it unreliable, so I had
stopped using Logitech devices to wake the machine. With v5 applied the
Bolt Receiver works consistently across many suspend/resume cycles (this
is what I observed in daily use; the three cycles above are the ones I
checked in the kernel log).

Thanks for the fix.

Maciej Zonski

Re: [PATCH] usb: pci-quirks: always assert xHCI OS ownership

[Michal Pecio]

On Sun, 16 Aug 2026 11:33:56 -0500, Mario Limonciello wrote:
> On 8/14/26 20:45, 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.

Not sure if this has anything to do with PROM21, or if some BIOS
is just trying to use the xHC at resume because it's permitted to.
Then it makes too many changes for Restore State to still work.

Potentially, such bugs may have happened and been left unsolved or
"solved" with RESET_ON_RESUME quirks and other hacks.

> > 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.
> > 
> > Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
> > 0x01000801 and eliminated the restore failure across four S3 cycles,
> > including a stock-kernel test. Clearing USBLEGCTLSTS was independently
> > verified to be unnecessary.
> > 
> > Always assert OS Owned when the xHCI Legacy Support capability is
> > present. Use the independently accessible ownership byte so firmware
> > can update BIOS Owned without racing a 32-bit read-modify-write. Keep
> > the existing BIOS handoff wait and legacy SMI cleanup unchanged.
> > 
> > Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
> > Tested-by: Rishabh Jain <rishabh.jain1198@gmail.com>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
> > ---
> > Additional context:
> > 
> > * Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
> >    behavior and its impact on attached USB devices:
> >    https://bugzilla.kernel.org/show_bug.cgi?id=216470
> > 
> > * Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
> >    xHC") is related workaround history: it tolerates a distinct AMD CSS
> >    timeout and resets the controller on resume:
> >    https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d
> > 
> > The external reports do not record their ownership semaphore values but
> > are included as corroborating failure signatures that this might fix.
> > 
> > drivers/usb/host/pci-quirks.c | 12 +++++++++---
> >   1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > index 0404489c2f6a..d76a4791b8f5 100644
> > --- a/drivers/usb/host/pci-quirks.c
> > +++ b/drivers/usb/host/pci-quirks.c
> > @@ -1185,6 +1185,14 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
> >   		dev_warn(&pdev->dev, "xHCI controller failing to respond");
> >   		goto iounmap;
> >   	}
> > +
> > +	/*
> > +	 * The OS ownership semaphore must be asserted while the OS owns the
> > +	 * xHC, even if firmware did not assert the BIOS ownership semaphore.
> > +	 * Update only the OS ownership byte to avoid racing with firmware.
> > +	 */
> > +	writeb(readb(base + ext_cap_offset + 3) | BIT(0),
> > +	       base + ext_cap_offset + 3);  
> 
> I'm assuming you are actually meaning XHCI_EXT_CAPS_PM for the 3 here. 
> Why are you doing all this math?
> 
> We already have the defines XHCI_HC_OS_OWNED, can't you just use that?
> 
> And for that matter it sounds like you are really proposing to just 
> remove this check but adding more complexity in the process.
> 
> 	if (val & XHCI_HC_BIOS_OWNED)

All explained by the comment above and xHCI 4.22.1.

Though curiously, while HW is required to enable doing the sensible
thing, the spec doesn't clearly state that SW must actually do it...

And BTW, I checked if any of my HCs refuses to honor DWORD writes to
this register to protect SW from itself, but none does.

> I guess the way I would do this is at least leave a debug breadcrumb

Is anyone ever going to look at that pci_debug()?

If it works, who cares if it was claimed by the BIOS or not.
If it doesn't, you know that it was. And the full register is dumped.

> since you're reading the register something like this:
> 
> val = readl(base + ext_cap_offset);
> if (val & XHCI_HC_BIOS_OWNED)
> 	pci_debug(pdev, "BIOS owns XHCI HC\n"0;
> writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
> timeout = handshake(...)
> if (timeout && (val & XHCI_HC_BIOS_OWNED)) {
> 	dev_warn(...)
> 	writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
> }
> 
> Then you have a single read, no extra writes.
> 
> >   	val = readl(base + ext_cap_offset);
> >   
> >   	/* Auto handoff never worked for these devices. Force it and continue */
> > @@ -1195,10 +1203,8 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
> >   		writel(val, base + ext_cap_offset);
> >   	}
> >   
> > -	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
> > +	/* If the BIOS owns the HC, wait for it to hand over control */
> >   	if (val & XHCI_HC_BIOS_OWNED) {
> > -		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
> > -
> >   		/* Wait for 1 second with 10 microsecond polling interval */
> >   		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
> >   				0, 1000000, 10);  
> 

Re: [PATCH] usb: pci-quirks: always assert xHCI OS ownership

[Mario Limonciello]

On 8/16/26 15:03, Michal Pecio wrote:
> On Sun, 16 Aug 2026 11:33:56 -0500, Mario Limonciello wrote:
>> On 8/14/26 20:45, 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.
> 
> Not sure if this has anything to do with PROM21, or if some BIOS
> is just trying to use the xHC at resume because it's permitted to.
> Then it makes too many changes for Restore State to still work.
> 
> Potentially, such bugs may have happened and been left unsolved or
> "solved" with RESET_ON_RESUME quirks and other hacks.

What do you think about making this a series with each of those quirks 
dropped one-by-one?  The head patch (a variation of this one) could go 
to stable and the rest of the commits dropping those can go to linux-next.

All the authors and associated people with thoes quirks can be CC'ed to 
give us a shot at cleaning up all of them.  If any continue to fail then 
it's a simple revert for each one that failed.

> 
>>> 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.
>>>
>>> Asserting only HC OS Owned changed USBLEGSUP from 0x00000801 to
>>> 0x01000801 and eliminated the restore failure across four S3 cycles,
>>> including a stock-kernel test. Clearing USBLEGCTLSTS was independently
>>> verified to be unnecessary.
>>>
>>> Always assert OS Owned when the xHCI Legacy Support capability is
>>> present. Use the independently accessible ownership byte so firmware
>>> can update BIOS Owned without racing a 32-bit read-modify-write. Keep
>>> the existing BIOS handoff wait and legacy SMI cleanup unchanged.
>>>
>>> Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
>>> Tested-by: Rishabh Jain <rishabh.jain1198@gmail.com>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
>>> ---
>>> Additional context:
>>>
>>> * Kernel Bugzilla #216470 documents the same USBSTS 0x401/reinitialize
>>>     behavior and its impact on attached USB devices:
>>>     https://bugzilla.kernel.org/show_bug.cgi?id=216470
>>>
>>> * Commit a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0
>>>     xHC") is related workaround history: it tolerates a distinct AMD CSS
>>>     timeout and resets the controller on resume:
>>>     https://github.com/torvalds/linux/commit/a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d
>>>
>>> The external reports do not record their ownership semaphore values but
>>> are included as corroborating failure signatures that this might fix.
>>>
>>> drivers/usb/host/pci-quirks.c | 12 +++++++++---
>>>    1 file changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
>>> index 0404489c2f6a..d76a4791b8f5 100644
>>> --- a/drivers/usb/host/pci-quirks.c
>>> +++ b/drivers/usb/host/pci-quirks.c
>>> @@ -1185,6 +1185,14 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>>>    		dev_warn(&pdev->dev, "xHCI controller failing to respond");
>>>    		goto iounmap;
>>>    	}
>>> +
>>> +	/*
>>> +	 * The OS ownership semaphore must be asserted while the OS owns the
>>> +	 * xHC, even if firmware did not assert the BIOS ownership semaphore.
>>> +	 * Update only the OS ownership byte to avoid racing with firmware.
>>> +	 */
>>> +	writeb(readb(base + ext_cap_offset + 3) | BIT(0),
>>> +	       base + ext_cap_offset + 3);
>>
>> I'm assuming you are actually meaning XHCI_EXT_CAPS_PM for the 3 here.
>> Why are you doing all this math?
>>
>> We already have the defines XHCI_HC_OS_OWNED, can't you just use that?
>>
>> And for that matter it sounds like you are really proposing to just
>> remove this check but adding more complexity in the process.
>>
>> 	if (val & XHCI_HC_BIOS_OWNED)
> 
> All explained by the comment above and xHCI 4.22.1.
> 
> Though curiously, while HW is required to enable doing the sensible
> thing, the spec doesn't clearly state that SW must actually do it...
> 
> And BTW, I checked if any of my HCs refuses to honor DWORD writes to
> this register to protect SW from itself, but none does.
> 
>> I guess the way I would do this is at least leave a debug breadcrumb
> 
> Is anyone ever going to look at that pci_debug()?
> 
> If it works, who cares if it was claimed by the BIOS or not.
> If it doesn't, you know that it was. And the full register is dumped.
> 

I guess I see your point.  This debug message I mentioned can probably 
be dropped in a v3.

>> since you're reading the register something like this:
>>
>> val = readl(base + ext_cap_offset);
>> if (val & XHCI_HC_BIOS_OWNED)
>> 	pci_debug(pdev, "BIOS owns XHCI HC\n"0;
>> writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
>> timeout = handshake(...)
>> if (timeout && (val & XHCI_HC_BIOS_OWNED)) {
>> 	dev_warn(...)
>> 	writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
>> }
>>
>> Then you have a single read, no extra writes.
>>
>>>    	val = readl(base + ext_cap_offset);
>>>    
>>>    	/* Auto handoff never worked for these devices. Force it and continue */
>>> @@ -1195,10 +1203,8 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>>>    		writel(val, base + ext_cap_offset);
>>>    	}
>>>    
>>> -	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
>>> +	/* If the BIOS owns the HC, wait for it to hand over control */
>>>    	if (val & XHCI_HC_BIOS_OWNED) {
>>> -		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
>>> -
>>>    		/* Wait for 1 second with 10 microsecond polling interval */
>>>    		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
>>>    				0, 1000000, 10);
>>

Re: [PATCH] usb: pci-quirks: always assert xHCI OS ownership

[Michal Pecio]

On Sun, 16 Aug 2026 16:00:47 -0500, Mario Limonciello wrote:
> On 8/16/26 15:03, Michal Pecio wrote:
> > Not sure if this has anything to do with PROM21, or if some BIOS
> > is just trying to use the xHC at resume because it's permitted to.
> > Then it makes too many changes for Restore State to still work.
> > 
> > Potentially, such bugs may have happened and been left unsolved or
> > "solved" with RESET_ON_RESUME quirks and other hacks.  
> 
> What do you think about making this a series with each of those
> quirks dropped one-by-one?  The head patch (a variation of this one)
> could go to stable and the rest of the commits dropping those can go
> to linux-next.

Hard to tell. All we have is a wild theory. I couldn't even test what
happens when the BIOS claims an unclaimed xHC during resume from S3,
because my BIOS doesn't do that even when I clear the "OS owned" bit
before suspending.

Those quirks may be wrong in the sense that they weren't specific to
the particular PCI IDs, but to some particular buggy BIOSes or kernels
in the past. Maybe those problems don't exist, maybe they still do.

I have completely disabled RESET_ON_RESUME on my test system with no
apparent ill efects so far.

OTOH, I tried disabling the "broken streams (UAS)" quirk on ASM1042.
While the kernel crash which those chips used to cause has been fixed
long ago, it turns out they just don't work correctly (Set TR Deq is
a No-Op with streams). So I'm not rushing to remove this quirk.

Regards,
Michal

Re: [PATCH] usb: pci-quirks: always assert xHCI OS ownership

[Mario Limonciello]

On 8/18/26 17:15, Michal Pecio wrote:
> On Sun, 16 Aug 2026 16:00:47 -0500, Mario Limonciello wrote:
>> On 8/16/26 15:03, Michal Pecio wrote:
>>> Not sure if this has anything to do with PROM21, or if some BIOS
>>> is just trying to use the xHC at resume because it's permitted to.
>>> Then it makes too many changes for Restore State to still work.
>>>
>>> Potentially, such bugs may have happened and been left unsolved or
>>> "solved" with RESET_ON_RESUME quirks and other hacks.
>>
>> What do you think about making this a series with each of those
>> quirks dropped one-by-one?  The head patch (a variation of this one)
>> could go to stable and the rest of the commits dropping those can go
>> to linux-next.
> 
> Hard to tell. All we have is a wild theory. I couldn't even test what
> happens when the BIOS claims an unclaimed xHC during resume from S3,
> because my BIOS doesn't do that even when I clear the "OS owned" bit
> before suspending.
> 
> Those quirks may be wrong in the sense that they weren't specific to
> the particular PCI IDs, but to some particular buggy BIOSes or kernels
> in the past. Maybe those problems don't exist, maybe they still do.
> 
> I have completely disabled RESET_ON_RESUME on my test system with no
> apparent ill efects so far.
> 
> OTOH, I tried disabling the "broken streams (UAS)" quirk on ASM1042.
> While the kernel crash which those chips used to cause has been fixed
> long ago, it turns out they just don't work correctly (Set TR Deq is
> a No-Op with streams). So I'm not rushing to remove this quirk.
> 
> Regards,
> Michal

So maybe we try with dropping RESET_ON_RESUME quirks only in this go around.