All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Niklas Neronin <niklas.neronin@linux.intel.com>
Cc: mathias.nyman@linux.intel.com, linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/7] usb: xhci-dbgcap: correct DMA address handling
Date: Tue, 9 Sep 2025 12:13:13 +0200	[thread overview]
Message-ID: <20250909121313.13286b34.michal.pecio@gmail.com> (raw)
In-Reply-To: <20250903170127.2190730-2-niklas.neronin@linux.intel.com>

On Wed,  3 Sep 2025 19:01:21 +0200, Niklas Neronin wrote:
> Address the handling of addresses within the dbc_handle_xfer_event(),
> ensuring accurate extraction and comparison.
> 
> Variable details:
> 'r->trb_dma'		    : A DMA address.
> 'ep_ctx->deq'		    : A le64, bits 63:4 contain the DMA address.
> 'event->trans_event.buffer' : A le64, bits 63:0 contain the DMA address.
> 
> 1. Convert 'ep_ctx->deq' and 'event->trans_event.buffer' addresses to
>    the CPU's native byte order.
> 
> 2. Use mask; TR_DEQ_PTR_MASK (bits 63:4) to extract the address from
>    'ep_ctx->deq', replacing the previous use of ~TRB_CYCLE (bits 63:1).
> 
> Why not use 'dma_addr_t' for the address?
> The 'dma_addr_t' type can vary between 32 and 64 bits depending on the
> system architecture or xHCI driver flags, whereas the 64-bit address field
> size remains constant. Since hardware cannot be fully trusted, it's better
> to print the entire 64-bit address to detect any non-zero values in the
> upper 32 bits. This approach ensures that potential issues are easily
> detected.
> 
> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
> ---
>  drivers/usb/host/xhci-dbgcap.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
> index 06a2edb9e86e..2f24a3a54439 100644
> --- a/drivers/usb/host/xhci-dbgcap.c
> +++ b/drivers/usb/host/xhci-dbgcap.c
> @@ -724,6 +724,7 @@ static void dbc_handle_xfer_event(struct xhci_dbc *dbc, union xhci_trb *event)
>  	u32			comp_code;
>  	size_t			remain_length;
>  	struct dbc_request	*req = NULL, *r;
> +	u64			ep_trb, deq;
>  
>  	comp_code	= GET_COMP_CODE(le32_to_cpu(event->generic.field[2]));
>  	remain_length	= EVENT_TRB_LEN(le32_to_cpu(event->generic.field[2]));
> @@ -733,10 +734,11 @@ static void dbc_handle_xfer_event(struct xhci_dbc *dbc, union xhci_trb *event)
>  	ep_ctx		= (ep_id == EPID_OUT) ?
>  				dbc_bulkout_ctx(dbc) : dbc_bulkin_ctx(dbc);
>  	ring		= dep->ring;
> +	ep_trb		= le64_to_cpu(event->trans_event.buffer);

In other places this variable would be called ep_trb_dma
and ep_trb would be xhci_trb*.

>  
>  	/* Match the pending request: */
>  	list_for_each_entry(r, &dep->list_pending, list_pending) {
> -		if (r->trb_dma == event->trans_event.buffer) {
> +		if (r->trb_dma == ep_trb) {

And here it is being compared with a something_dma variable.

>  			req = r;
>  			break;
>  		}
> @@ -768,8 +770,9 @@ static void dbc_handle_xfer_event(struct xhci_dbc *dbc, union xhci_trb *event)
>  		status = -comp_code;
>  		break;
>  	case COMP_STALL_ERROR:
> +		deq = le64_to_cpu(ep_ctx->deq) & TR_DEQ_PTR_MASK;
>  		dev_warn(dbc->dev, "Stall error at bulk TRB %llx, remaining %zu, ep deq %llx\n",
> -			 event->trans_event.buffer, remain_length, ep_ctx->deq);
> +			 ep_trb, remain_length, deq);
>  		status = 0;
>  		dep->halted = 1;
>  
> @@ -788,7 +791,7 @@ static void dbc_handle_xfer_event(struct xhci_dbc *dbc, union xhci_trb *event)
>  		 * TRB again.
>  		 */
>  
> -		if ((ep_ctx->deq & ~TRB_CYCLE) == event->trans_event.buffer) {
> +		if (deq == ep_trb) {
>  			dev_dbg(dbc->dev, "Ep stopped on Stalled TRB\n");
>  			if (remain_length == req->length) {
>  				dev_dbg(dbc->dev, "Spurious stall event, keep req\n");
> -- 
> 2.50.1
> 

  reply	other threads:[~2025-09-09 10:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 17:01 [PATCH 0/7] usb: xhci: enhancements to address printing Niklas Neronin
2025-09-03 17:01 ` [PATCH 1/7] usb: xhci-dbgcap: correct DMA address handling Niklas Neronin
2025-09-09 10:13   ` Michal Pecio [this message]
2025-09-10  8:00     ` Neronin, Niklas
2025-09-10  8:15       ` Michal Pecio
2025-09-03 17:01 ` [PATCH 2/7] usb: xhci: use '%pad' specifier for DMA address printing Niklas Neronin
2025-09-09  9:59   ` Michal Pecio
2025-09-09 11:29     ` Andy Shevchenko
2025-09-09 20:44       ` Michal Pecio
2025-09-10  5:56         ` Michal Pecio
2025-09-11  7:41           ` Andy Shevchenko
2025-09-11  9:34             ` Michal Pecio
2025-09-11 20:13               ` Andy Shevchenko
2025-09-12  9:46                 ` Michal Pecio
2025-09-12 18:02                   ` Andy Shevchenko
2025-09-13  8:12                     ` Michal Pecio
2025-09-15  7:20                       ` Andy Shevchenko
2025-09-15 10:22                         ` Michal Pecio
2025-09-15 12:32                           ` Neronin, Niklas
2025-09-16  9:32                             ` Michal Pecio
2025-09-16  9:36                               ` Michal Pecio
2025-09-15 14:22                           ` Andy Shevchenko
2025-09-10  9:04   ` Michal Pecio
2025-09-10  9:17     ` Michal Pecio
2025-09-03 17:01 ` [PATCH 3/7] usb: xhci: improve Stream Context register debugging Niklas Neronin
2025-09-09  9:23   ` Michal Pecio
2025-09-03 17:01 ` [PATCH 4/7] usb: xhci: improve Endpoint " Niklas Neronin
2025-09-09  9:20   ` Michal Pecio
2025-09-09 10:24     ` Michal Pecio
2025-09-15 12:45     ` Neronin, Niklas
2025-09-03 17:01 ` [PATCH 5/7] usb: xhci: improve Command Ring Control " Niklas Neronin
2025-09-09  9:17   ` Michal Pecio
2025-09-09 10:20     ` Michal Pecio
2025-09-03 17:01 ` [PATCH 6/7] usb: xhci: improve Event Ring Dequeue Pointer Register debugging Niklas Neronin
2025-09-03 17:01 ` [PATCH 7/7] usb: xhci: standardize address format Niklas Neronin
2025-09-09  9:06   ` Michal Pecio
2025-09-15 13:24     ` Neronin, Niklas

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=20250909121313.13286b34.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=niklas.neronin@linux.intel.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.