[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <795371f5-b11a-4348-a838-f56326d5ca2c@gmail.com>
Date: Mon, 10 Feb 2025 20:23:28 +0100
From: Ferry Toth <fntoth@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thinh Nguyen <Thinh.Nguyen@...opsys.com>, Felipe Balbi <balbi@...nel.org>,
linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH v2 0/3] usb: dwc3: Avoid using reserved EPs
Op 03-02-2025 om 20:10 schreef Andy Shevchenko:
>
> On some platforms (Intel-based and AFAIK ARM-based) the EPs in the gadget
> (USB Device Controller mode) may be reserved for some special means, such as
> tracing. This series extends DT schema and driver to avoid using those.
> Without this the USB gadget mode won't work properly (those devices that
> "luckily" allocated the reserved EPs).
>
> Ferry already tested the previous versions, but I ask him again to
> re-test this version which is significantly rewritten. I have not
> applied given tag just to be sure we got it carefully tested again.
>
> Changelog v2:
> - added minItems to the schema (Rob)
> - revisited code and add NULL check to avoid crashes (Thinh)
> - rewrote helper function to return error to the user if parsing fails
> - elaborated in the commit message why we need this quirk (Thinh)
> - addressed miscellaneous style issues (Thinh)
>
> Andy Shevchenko (3):
> dt-bindings: usb: dwc3: Add a property to reserve endpoints
> usb: dwc3: gadget: Add support for snps,reserved-endpoints property
> usb: dwc3: gadget: Avoid using reserved endpoints on Intel Merrifield
>
> .../bindings/usb/snps,dwc3-common.yaml | 11 ++++
> drivers/usb/dwc3/dwc3-pci.c | 10 ++++
> drivers/usb/dwc3/gadget.c | 60 +++++++++++++++++--
> 3 files changed, 76 insertions(+), 5 deletions(-)
>
Retested this on v6.13.0 Intel Merrifield and found no problems due to
this patch. With simultaneous iperf3 on cdc eem, and a disk bench mark
on mass storage, it is possible to overload the gadgets causing no or
delayed responses (delayed until killing iperf3) on gser, eventually
causing the host side to need a reboot. So, nothing new there :-)
Thanks!
Tested-by: Ferry Toth <fntoth@...il.com>
Powered by blists - more mailing lists