[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] 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.

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

[McKenna Fan]

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