From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Łukasz Bartosik" <ukaszb@chromium.org>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH v1] xhci: dbc: fix handling ClearFeature Halt requests
Date: Mon, 22 Jul 2024 18:31:12 +0200 [thread overview]
Message-ID: <2024072255-grass-monastery-c7db@gregkh> (raw)
In-Reply-To: <20240722150738.61486-1-ukaszb@chromium.org>
On Mon, Jul 22, 2024 at 03:07:38PM +0000, Łukasz Bartosik wrote:
> DbC driver does not handle ClearFeature Halt requests correctly
> which in turn may lead to dropping packets on the receive path.
>
> Below is a trace capture where due to incorrect handling of
> ClearFeature Halt packet gets dropped on the receive path.
>
> /sys/kernel/debug/tracing # cat trace
> 1) kworker/10:3-514 [010] d..1. 2925.601843: xhci_dbc_handle_event:
> EVENT: TRB 000000019588c0e0 status 'Stall Error' len 0 slot 1 ep 2
> type 'Transfer Event' flags e:C
>
> 2) kworker/10:3-514 [010] d..1. 2925.613285: xhci_dbc_handle_event:
> EVENT: TRB 000000019588bc80 status 'Stall Error' len 1024 slot 1
> ep 3 type 'Transfer Event' flags e:C
>
> 3) kworker/10:3-514 [010] d..1. 2925.619024: xhci_dbc_handle_transfer:
> BULK: Buffer 0000000244b49800 length 1024 TD size 0 intr 0 type
> 'Normal' flags b:i:I:c:s:i:e:C
>
> 4) kworker/10:3-514 [010] d..1. 2925.619025: xhci_dbc_giveback_request:
> bulk-in: req 00000000a70b5ad2 length 0/1024 ==> -6
>
> 5) kworker/10:3-514 [010] dNs2. 2925.623820: xhci_dbc_gadget_ep_queue:
> BULK: Buffer 0000000244b49800 length 1024 TD size 0 intr 0 type
> 'Normal' flags b:i:I:c:s:i:e:c
>
> 6) kworker/10:3-514 [010] dNs1. 2925.623823: xhci_dbc_queue_request:
> bulk-in: req 00000000a70b5ad2 length 0/1024 ==> -115
>
> 7) kworker/10:3-514 [010] d..1. 2925.629865: xhci_dbc_handle_event:
> EVENT: TRB 000000019588bc80 status 'Short Packet' len 1000 slot 1
> ep 3 type 'Transfer Event' flags e:C
>
> 8) kworker/10:3-514 [010] d..1. 2925.635540: xhci_dbc_handle_event:
> EVENT: TRB 000000019588bc90 status 'Short Packet' len 763 slot 1
> ep 3 type 'Transfer Event' flags e:C
>
> 9) kworker/10:3-514 [010] d..1. 2925.635540: xhci_dbc_handle_transfer:
> BULK: Buffer 0000000244b49c00 length 1024 TD size 0 intr 0 type
> 'Normal' flags b:i:I:c:s:i:e:C
>
> 10) kworker/10:3-514 [010] d..1. 2925.635541: xhci_dbc_giveback_request:
> bulk-in: req 00000000b4ec77d7 length 261/1024 ==> 0
>
> 11) kworker/10:3-514 [010] dNs2. 2925.635561: xhci_dbc_gadget_ep_queue:
> BULK: Buffer 0000000244b49c00 length 1024 TD size 0 intr 0 type
> 'Normal' flags b:i:I:c:s:i:e:c
>
> 12) kworker/10:3-514 [010] dNs1. 2925.635562: xhci_dbc_queue_request:
> bulk-in: req 00000000b4ec77d7 length 0/1024 ==> -115
>
> Lines 1 and 2 are Endpoints OUT and IN responses to receiving ClearFeature
> Halt requests.
>
> Line 7 notifies of reception of 24 bytes packet.
>
> Line 8 notifies of reception of 261 bytes packet
>
> In Lines [9, 12] 261 bytes packet is being processed.
>
> However 24 bytes packet gets dropped. The kernel log includes entry which
> is an indication of a packet drop:
> [ 127.651845] xhci_hcd 0000:00:0d.0: no matched request
>
> This fix adds correct handling of ClearFeature Halt requests
> by restarting an endpoint which received the request.
>
> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
> Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org>
> ---
> drivers/usb/host/xhci-dbgcap.c | 29 +++++++++++++++++++----------
> drivers/usb/host/xhci-dbgtty.c | 5 +++++
> 2 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
> index 872d9cddbcef..b7af3a5ac98a 100644
> --- a/drivers/usb/host/xhci-dbgcap.c
> +++ b/drivers/usb/host/xhci-dbgcap.c
> @@ -173,7 +173,7 @@ static void xhci_dbc_giveback(struct dbc_request *req, int status)
> spin_lock(&dbc->lock);
> }
>
> -static void xhci_dbc_flush_single_request(struct dbc_request *req)
> +static void xhci_dbc_flush_single_request(struct dbc_request *req, int status)
So now we need to look up what "status" is here for every place this is
called? That's going to be a pain, as you didn't even document it :(
thanks,
greg k-h
next prev parent reply other threads:[~2024-07-22 16:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-22 15:07 [PATCH v1] xhci: dbc: fix handling ClearFeature Halt requests Łukasz Bartosik
2024-07-22 16:31 ` Greg Kroah-Hartman [this message]
2024-07-22 23:17 ` Łukasz Bartosik
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=2024072255-grass-monastery-c7db@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=baolu.lu@linux.intel.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=ukaszb@chromium.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.