Linux USB
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Rishabh Jain <rishabh.jain1198@gmail.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mario Limonciello <superm1@kernel.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v3] usb: pci-quirks: always assert xHCI OS ownership
Date: Tue, 1 Sep 2026 12:13:43 +0200	[thread overview]
Message-ID: <20260901121343.22786f2d.michal.pecio@gmail.com> (raw)
In-Reply-To: <20260831211126.23745-1-rishabh.jain1198@gmail.com>

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

  parent reply	other threads:[~2026-09-01 10:13 UTC|newest]

Thread overview: 14+ 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 [this message]
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-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

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=20260901121343.22786f2d.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=rishabh.jain1198@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=superm1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox