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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox