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 privately sent PoC of this, but I ask him again to
re-test this version which is slightly different.

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: Skip endpoints ep[18]{in,out} on Intel Merrifield

 .../devicetree/bindings/usb/snps,dwc3.yaml    | 10 +++++
 drivers/usb/dwc3/dwc3-pci.c                   |  9 +++++
 drivers/usb/dwc3/gadget.c                     | 38 ++++++++++++++++++-
 3 files changed, 56 insertions(+), 1 deletion(-)

-- 
2.43.0.rc1.1336.g36b5255a03ac

Op 16-01-2025 om 16:40 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 privately sent PoC of this, but I ask him again to
> re-test this version which is slightly different.
> 
> 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: Skip endpoints ep[18]{in,out} on Intel Merrifield
> 
>   .../devicetree/bindings/usb/snps,dwc3.yaml    | 10 +++++
>   drivers/usb/dwc3/dwc3-pci.c                   |  9 +++++
>   drivers/usb/dwc3/gadget.c                     | 38 ++++++++++++++++++-
>   3 files changed, 56 insertions(+), 1 deletion(-)
> 
Yes I retested this now on v6.13.0-rc7 Intel Merrifield and found no 
problems. Skipping the tracing end point has definitely always been 
needed on this platform. Thanks!

Tested-by: Ferry Toth <fntoth@gmail.com>

On Thu, Jan 16, 2025, Andy Shevchenko wrote:
> 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 privately sent PoC of this, but I ask him again to
> re-test this version which is slightly different.
> 
> 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: Skip endpoints ep[18]{in,out} on Intel Merrifield
> 
>  .../devicetree/bindings/usb/snps,dwc3.yaml    | 10 +++++
>  drivers/usb/dwc3/dwc3-pci.c                   |  9 +++++
>  drivers/usb/dwc3/gadget.c                     | 38 ++++++++++++++++++-
>  3 files changed, 56 insertions(+), 1 deletion(-)
> 
> -- 
> 2.43.0.rc1.1336.g36b5255a03ac
> 

I'm not entirely clear on the reason for this change yet.

How would this even work without dwc3 managing these endpoints (all the
init/teardown/fifo allocation/start/stop flow). Can you provide more
info on this hardware?

Thanks,
Thinh

On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote:
> On Thu, Jan 16, 2025, Andy Shevchenko wrote:
> > 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 privately sent PoC of this, but I ask him again to
> > re-test this version which is slightly different.

...

> I'm not entirely clear on the reason for this change yet.
> 
> How would this even work without dwc3 managing these endpoints (all the
> init/teardown/fifo allocation/start/stop flow).

You perhaps know much better how it can be done, I have access to a limited
documentation and in practice if those endpoints are not skipped any gadget
that allocates them simply won't work, and IIRC the entire USB transfers are
stuck.

> Can you provide more info on this hardware?

I am afraid I can't provide more, sorry. I can look for some specifics,
but I'm not that guy who know anything about in-SoC tracing.

-- 
With Best Regards,
Andy Shevchenko

On Fri, Jan 17, 2025 at 03:38:46PM +0200, Andy Shevchenko wrote:
> On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote:
> > On Thu, Jan 16, 2025, Andy Shevchenko wrote:
> > > 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 privately sent PoC of this, but I ask him again to
> > > re-test this version which is slightly different.

...

> > I'm not entirely clear on the reason for this change yet.
> > 
> > How would this even work without dwc3 managing these endpoints (all the
> > init/teardown/fifo allocation/start/stop flow).
> 
> You perhaps know much better how it can be done, I have access to a limited
> documentation and in practice if those endpoints are not skipped any gadget
> that allocates them simply won't work, and IIRC the entire USB transfers are
> stuck.
> 
> > Can you provide more info on this hardware?
> 
> I am afraid I can't provide more, sorry. I can look for some specifics,
> but I'm not that guy who know anything about in-SoC tracing.

So, here is what I found:

---8<---

However the endpoints allocated for STM and EXI debug traffic cannot be re-allocated
if being used because the sideband flow control signals are hard wired to certain
endpoints:
• 1 High BW Bulk IN (IN#1) (RTIT)
• 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8)

In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer
Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by
EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System
Trace Module) unit and the EXI target driver will as well configure the TRB location for
EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage
these endpoints and interface to OTG3 controller through EBC interface, there is no
need to enable any events (such as XferComplete etc) for these end points.

Does it help you to understand the required quirk better?

-- 
With Best Regards,
Andy Shevchenko

On Mon, Jan 20, 2025, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 03:38:46PM +0200, Andy Shevchenko wrote:
> > On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote:
> > > On Thu, Jan 16, 2025, Andy Shevchenko wrote:
> > > > 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 privately sent PoC of this, but I ask him again to
> > > > re-test this version which is slightly different.
> 
> ...
> 
> > > I'm not entirely clear on the reason for this change yet.
> > > 
> > > How would this even work without dwc3 managing these endpoints (all the
> > > init/teardown/fifo allocation/start/stop flow).
> > 
> > You perhaps know much better how it can be done, I have access to a limited
> > documentation and in practice if those endpoints are not skipped any gadget
> > that allocates them simply won't work, and IIRC the entire USB transfers are
> > stuck.
> > 
> > > Can you provide more info on this hardware?
> > 
> > I am afraid I can't provide more, sorry. I can look for some specifics,
> > but I'm not that guy who know anything about in-SoC tracing.
> 
> So, here is what I found:
> 
> ---8<---
> 
> However the endpoints allocated for STM and EXI debug traffic cannot be re-allocated
> if being used because the sideband flow control signals are hard wired to certain
> endpoints:
> • 1 High BW Bulk IN (IN#1) (RTIT)
> • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8)
> 
> In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer
> Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by
> EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System
> Trace Module) unit and the EXI target driver will as well configure the TRB location for
> EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage
> these endpoints and interface to OTG3 controller through EBC interface, there is no
> need to enable any events (such as XferComplete etc) for these end points.
> 
> Does it help you to understand the required quirk better?
> 

Thanks for looking up the info. This makes more sense now. So these
endpoints use EBC. Can you also provide this info to the commit?

BR,
Thinh

On Tue, Jan 21, 2025 at 11:43:21PM +0000, Thinh Nguyen wrote:
> On Mon, Jan 20, 2025, Andy Shevchenko wrote:
> > On Fri, Jan 17, 2025 at 03:38:46PM +0200, Andy Shevchenko wrote:
> > > On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote:
> > > > On Thu, Jan 16, 2025, Andy Shevchenko wrote:

...

> > > > I'm not entirely clear on the reason for this change yet.
> > > > 
> > > > How would this even work without dwc3 managing these endpoints (all the
> > > > init/teardown/fifo allocation/start/stop flow).
> > > 
> > > You perhaps know much better how it can be done, I have access to a limited
> > > documentation and in practice if those endpoints are not skipped any gadget
> > > that allocates them simply won't work, and IIRC the entire USB transfers are
> > > stuck.
> > > 
> > > > Can you provide more info on this hardware?
> > > 
> > > I am afraid I can't provide more, sorry. I can look for some specifics,
> > > but I'm not that guy who know anything about in-SoC tracing.
> > 
> > So, here is what I found:
> > 
> > ---8<---
> > 
> > However the endpoints allocated for STM and EXI debug traffic cannot be re-allocated
> > if being used because the sideband flow control signals are hard wired to certain
> > endpoints:
> > • 1 High BW Bulk IN (IN#1) (RTIT)
> > • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8)
> > 
> > In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer
> > Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by
> > EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System
> > Trace Module) unit and the EXI target driver will as well configure the TRB location for
> > EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage
> > these endpoints and interface to OTG3 controller through EBC interface, there is no
> > need to enable any events (such as XferComplete etc) for these end points.
> > 
> > ---8<---
> > 
> > Does it help you to understand the required quirk better?
> 
> Thanks for looking up the info. This makes more sense now. So these
> endpoints use EBC. Can you also provide this info to the commit?

Sure, since I published it already it makes no difference if it appears in the
Git log (from the publicity point of view).

-- 
With Best Regards,
Andy Shevchenko

On Wed, Jan 22, 2025, Andy Shevchenko wrote:
> On Tue, Jan 21, 2025 at 11:43:21PM +0000, Thinh Nguyen wrote:
> > On Mon, Jan 20, 2025, Andy Shevchenko wrote:
> > > On Fri, Jan 17, 2025 at 03:38:46PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote:
> > > > > On Thu, Jan 16, 2025, Andy Shevchenko wrote:
> 
> ...
> 
> > > > > I'm not entirely clear on the reason for this change yet.
> > > > > 
> > > > > How would this even work without dwc3 managing these endpoints (all the
> > > > > init/teardown/fifo allocation/start/stop flow).
> > > > 
> > > > You perhaps know much better how it can be done, I have access to a limited
> > > > documentation and in practice if those endpoints are not skipped any gadget
> > > > that allocates them simply won't work, and IIRC the entire USB transfers are
> > > > stuck.
> > > > 
> > > > > Can you provide more info on this hardware?
> > > > 
> > > > I am afraid I can't provide more, sorry. I can look for some specifics,
> > > > but I'm not that guy who know anything about in-SoC tracing.
> > > 
> > > So, here is what I found:
> > > 
> > > ---8<---
> > > 
> > > However the endpoints allocated for STM and EXI debug traffic cannot be re-allocated
> > > if being used because the sideband flow control signals are hard wired to certain
> > > endpoints:
> > > • 1 High BW Bulk IN (IN#1) (RTIT)
> > > • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8)
> > > 
> > > In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer
> > > Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by
> > > EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System
> > > Trace Module) unit and the EXI target driver will as well configure the TRB location for
> > > EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage
> > > these endpoints and interface to OTG3 controller through EBC interface, there is no
> > > need to enable any events (such as XferComplete etc) for these end points.
> > > 
> > > ---8<---
> > > 
> > > Does it help you to understand the required quirk better?
> > 
> > Thanks for looking up the info. This makes more sense now. So these
> > endpoints use EBC. Can you also provide this info to the commit?
> 
> Sure, since I published it already it makes no difference if it appears in the
> Git log (from the publicity point of view).
> 

It's more difficult to find this outside of git log, especially to a
link version of a git change that's not applied.

BR,
Thinh

On Tue, Jan 28, 2025 at 02:25:21AM +0000, Thinh Nguyen wrote:
> On Wed, Jan 22, 2025, Andy Shevchenko wrote:
> > On Tue, Jan 21, 2025 at 11:43:21PM +0000, Thinh Nguyen wrote:
> > > On Mon, Jan 20, 2025, Andy Shevchenko wrote:
> > > > On Fri, Jan 17, 2025 at 03:38:46PM +0200, Andy Shevchenko wrote:
> > > > > On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote:
> > > > > > On Thu, Jan 16, 2025, Andy Shevchenko wrote:

...

> > > > > > I'm not entirely clear on the reason for this change yet.
> > > > > > 
> > > > > > How would this even work without dwc3 managing these endpoints (all the
> > > > > > init/teardown/fifo allocation/start/stop flow).
> > > > > 
> > > > > You perhaps know much better how it can be done, I have access to a limited
> > > > > documentation and in practice if those endpoints are not skipped any gadget
> > > > > that allocates them simply won't work, and IIRC the entire USB transfers are
> > > > > stuck.
> > > > > 
> > > > > > Can you provide more info on this hardware?
> > > > > 
> > > > > I am afraid I can't provide more, sorry. I can look for some specifics,
> > > > > but I'm not that guy who know anything about in-SoC tracing.
> > > > 
> > > > So, here is what I found:
> > > > 
> > > > ---8<---
> > > > 
> > > > However the endpoints allocated for STM and EXI debug traffic cannot be re-allocated
> > > > if being used because the sideband flow control signals are hard wired to certain
> > > > endpoints:
> > > > • 1 High BW Bulk IN (IN#1) (RTIT)
> > > > • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8)
> > > > 
> > > > In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer
> > > > Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by
> > > > EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System
> > > > Trace Module) unit and the EXI target driver will as well configure the TRB location for
> > > > EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage
> > > > these endpoints and interface to OTG3 controller through EBC interface, there is no
> > > > need to enable any events (such as XferComplete etc) for these end points.
> > > > 
> > > > ---8<---
> > > > 
> > > > Does it help you to understand the required quirk better?
> > > 
> > > Thanks for looking up the info. This makes more sense now. So these
> > > endpoints use EBC. Can you also provide this info to the commit?
> > 
> > Sure, since I published it already it makes no difference if it appears in the
> > Git log (from the publicity point of view).
> 
> It's more difficult to find this outside of git log, especially to a
> link version of a git change that's not applied.

I'm not objecting this, what I am telling is that information went public in
this thread, so expanding a commit message in the next version of the series
to include additional information is fine with me. I'll do that.

-- 
With Best Regards,
Andy Shevchenko