From: Mario Limonciello <superm1@kernel.org>
To: Rishabh Jain <rishabh.jain1198@gmail.com>,
Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michal Pecio <michal.pecio@gmail.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v5] usb: pci-quirks: always assert xHCI OS ownership
Date: Mon, 12 Oct 2026 15:14:14 -0500 [thread overview]
Message-ID: <7d64e267-8ca6-4130-bd4a-d80fb4224f72@kernel.org> (raw)
In-Reply-To: <178832755831.50581.1058201741431375556@gmail.com>
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);
> }
> }
>
next prev parent reply other threads:[~2026-10-12 20:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 1:45 [PATCH] usb: pci-quirks: always assert xHCI OS ownership Rishabh Jain
2026-08-16 16:33 ` Mario Limonciello
2026-08-16 18:15 ` [PATCH v2] " Rishabh Jain
2026-08-31 10:09 ` Greg Kroah-Hartman
2026-08-31 21:11 ` [PATCH v3] " Rishabh Jain
2026-08-31 21:27 ` Mario Limonciello
2026-09-01 10:13 ` Michal Pecio
2026-09-02 1:24 ` [PATCH v4] " Rishabh Jain
2026-09-02 3:26 ` Michal Pecio
2026-09-02 5:39 ` [PATCH v5] " Rishabh Jain
2026-10-12 20:14 ` Mario Limonciello [this message]
2026-08-16 20:03 ` [PATCH] " Michal Pecio
2026-08-16 21:00 ` Mario Limonciello
2026-08-18 22:15 ` Michal Pecio
2026-08-21 20:52 ` Mario Limonciello
-- strict thread matches above, loose matches on Subject: below --
2026-09-11 15:13 [PATCH v5] " McKenna Fan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d64e267-8ca6-4130-bd4a-d80fb4224f72@kernel.org \
--to=superm1@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=michal.pecio@gmail.com \
--cc=rishabh.jain1198@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.