[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025062832-pebble-superhero-fbbc@gregkh>
Date: Sat, 28 Jun 2025 17:18:23 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: SCHNEIDER Johannes <johannes.schneider@...ca-geosystems.com>
Cc: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
GEO-CHHER-bsp-development <bsp-development.geo@...ca-geosystems.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] usb: dwc3: gadget: Fix TRB reclaim logic for short
transfers and ZLPs
On Wed, Jun 25, 2025 at 07:49:16AM +0000, SCHNEIDER Johannes wrote:
> Commit 96c7bf8f6b3e ("usb: dwc3: gadget: Cleanup SG handling") updated
> the TRB reclaim path to use the TRB CHN (Chain) bit to determine whether
> a TRB was part of a chain. However, this inadvertently changed the
> behavior of reclaiming the final TRB in some scatter-gather or short
> transfer cases.
>
> In particular, if the final TRB did not have the CHN bit set, the
> cleanup path could incorrectly skip clearing the HWO (Hardware Own)
> bit, leaving stale TRBs in the ring. This resulted in broken data
> transfer completions in userspace, notably for MTP over FunctionFS.
>
> Fix this by unconditionally clearing the HWO bit during TRB reclaim,
> regardless of the CHN bit state. This restores correct behavior
> especially for transfers that require ZLPs or end on non-CHN TRBs.
>
> Fixes 61440628a4ff ("usb: dwc3: gadget: Cleanup SG handling")
> Signed-off-by: Johannes Schneider <johannes.schneider@...ca-geosystems.com>
> Acked-by: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
> Cc: <stable@...r.kernel.org> # v6.13
> ---
> v3: no changes, re-submission as single patch, with Cc stable
> v2: no changes to the patch, "faulty" re-submission
> v1: initial submission as part of a series
> Link: https://lore.kernel.org/lkml/AM8PR06MB7521CFF1CD8A93622A537EEDBC78A@AM8PR06MB7521.eurprd06.prod.outlook.com/
>
> drivers/usb/dwc3/gadget.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 321361288935..99fbd29d8f46 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -3516,7 +3516,7 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
> * We're going to do that here to avoid problems of HW trying
> * to use bogus TRBs for transfers.
> */
> - if (chain && (trb->ctrl & DWC3_TRB_CTRL_HWO))
> + if (trb->ctrl & DWC3_TRB_CTRL_HWO)
> trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
>
> /*
> --
> 2.43.0
>
How was this tested:
drivers/usb/dwc3/gadget.c: In function ‘dwc3_gadget_ep_reclaim_completed_trb’:
drivers/usb/dwc3/gadget.c:3519:13: error: ‘chain’ undeclared (first use in this function)
3519 | if (chain && (trb->ctrl & DWC3_TRB_CTRL_HWO))
| ^~~~~
drivers/usb/dwc3/gadget.c:3519:13: note: each undeclared identifier is reported only once for each function it appears in
Ugh, b4 is picking up the wrong thing here...
Can you resend these as NOT part of an existing email thread if you want
them to be applied on their own?
thanks,
greg k-h
Powered by blists - more mailing lists