All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Cc: mathias.nyman@intel.com, gregkh@linuxfoundation.org,
	oneukum@suse.com, linux-usb@vger.kernel.org,
	arien.judge@morsemicro.com
Subject: Re: [RFC PATCH] usb: xhci: use BIT_ULL for CRCR bits
Date: Thu, 30 Jul 2026 10:04:34 +0200	[thread overview]
Message-ID: <20260730100434.3354b600.michal.pecio@gmail.com> (raw)
In-Reply-To: <20260730054521.296139-1-lachlan.hodges@morsemicro.com>

On Thu, 30 Jul 2026 15:45:21 +1000, Lachlan Hodges wrote:
> The CRCR register is 64 bits wide - commit abe93f27cdd7
> ("xhci: use BIT macro") changed the flag definitions from (1 << n),
> a signed int, to BIT(n), an unsigned long. Within
> xhci_set_cmd_ring_deq(), the following operation is performed on the
> CRCR register:
> 
> ...
> 	crcr &= ~CMD_RING_PTR_MASK;
> 	crcr |= deq_dma;
> 	crcr &= ~CMD_RING_CYCLE;
> 	crcr |= xhci->cmd_ring->cycle_state;
> ...
> 
> Previously, ~CMD_RING_CYCLE was ~(int)1, a negative signed value
> (0xFFFFFFFE with the sign bit set). Widening a negative signed int to
> u64 sign-extends it to 0xFFFFFFFFFFFFFFFE, correctly clearing only bit
> 0 and preserving the 64-bit pointer written two lines above.
> 
> After the change when running on 32 bit kernels, ~CMD_RING_CYCLE is
> ~(unsigned long)1UL. On a 32-bit host this is an unsigned 32-bit
> value (0xFFFFFFFE, no sign bit). Widening an unsigned value to u64
> zero-extends it instead (0x00000000FFFFFFFE), so the subsequent AND
> silently clears bits 63:32 of crcr, truncating the command ring
> pointer that was just written before the value reaches hardware.
> 
> To fix, similar to how CMD_RING_PTR_MASK is defined, make sure we
> use the BIT_ULL variant when defining the CRCR bits.
> 
> Fixes: abe93f27cdd7 ("xhci: use BIT macro")
> Assisted-by: Claude:claude-sonnet-5
> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
> ---
> 
> Hi, I experienced this when running the tip of wireless-next on
> a raspberry pi 4B compiled for arm32. The main symptoms were the
> following log message:
> 
> [    0.549897] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-02-25T12:11:39
> [    0.626859] xhci_hcd 0000:01:00.0: xHCI Host Controller
> [    0.626889] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
> [    0.812619] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000200000000890
> [    0.813188] xhci_hcd 0000:01:00.0: xHCI Host Controller
> [    0.813203] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
> [    0.813219] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed
> [    0.813602] hub 1-0:1.0: USB hub found
> [    0.814052] hub 2-0:1.0: USB hub found
> [    0.952714] xhci_hcd 0000:01:00.0: ERROR mismatched command completion event
> 
> Additionally running lsusb just hangs. Running the same kernel compiled
> for aarch64 worked fine. Bisected to the commit in the Fixes line
> above. Additionally a USB device plugged in to the USB3.0 (or 2.0)
> did not enumerate. Once this patch is applied the USB device
> enumerates properly on the tip of wireless-next 4a0bd262df75 ("wifi:
> mac80211: fix per-STA profile length in cross-link CSA parsing").

Makes sense, including observed symptoms.

A system with IOMMU would fault on top of that, but the accesses
are reads, so hopefully no corruption in absence of IOMMU.

> Happy to test alternate fix proposals! Thanks.

I think the sort of code you quoted should work without surprises,
so widening these macros to ULL is right.

And there is a few more. They currently don't break anything, but
neither does CMD_RING_ABORT or CMD_RING_RUNNING for that matter.

ERST_EHB
EP_CTX_CYCLE_MASK

Let's see what Mathias thinks about it.

> 
> lachlan
> ---
>  drivers/usb/host/xhci.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index d02046a573e4..df014855c659 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -190,13 +190,13 @@ struct xhci_op_regs {
>  
>  /* CRCR - Command Ring Control Register - cmd_ring bitmasks */
>  /* bit 0 - Cycle bit indicates the ownership of the command ring */
> -#define CMD_RING_CYCLE		BIT(0)
> +#define CMD_RING_CYCLE		BIT_ULL(0)
>  /* stop ring operation after completion of the currently executing command */
> -#define CMD_RING_PAUSE		BIT(1)
> +#define CMD_RING_PAUSE		BIT_ULL(1)
>  /* stop ring immediately - abort the currently executing command */
> -#define CMD_RING_ABORT		BIT(2)
> +#define CMD_RING_ABORT		BIT_ULL(2)
>  /* true: command ring is running */
> -#define CMD_RING_RUNNING	BIT(3)
> +#define CMD_RING_RUNNING	BIT_ULL(3)
>  /* bits 63:6 - Command Ring pointer */
>  #define CMD_RING_PTR_MASK	GENMASK_ULL(63, 6)
>  
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-07-30  8:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30  5:45 [RFC PATCH] usb: xhci: use BIT_ULL for CRCR bits Lachlan Hodges
2026-07-30  8:04 ` Michal Pecio [this message]
2026-07-30  9:07   ` Mathias Nyman

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=20260730100434.3354b600.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=arien.judge@morsemicro.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lachlan.hodges@morsemicro.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=oneukum@suse.com \
    /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.