When multiple DWC3 controllers are being used, trace events from
different instances get mixed up making debugging difficult as
there's no way to distinguish which instance generated the trace.

Hence append the controller base address into ftrace. This needs
the following reworks which is addressed using this patch series.

  1. Removal of dep->regs and use dwc->regs everywhere
  2. Use dwc pointer in all dwc3_readl/writel()
  3. Adding the base addr in traces.

Changes in v2:
- Avoid using macros for dwc3_readl/writel()
- Use base address intraces instead of dev name.
- Split the patch into a series.
- Link to v1: https://lore.kernel.org/all/20250825114433.3170867-1-prashanth.k@oss.qualcomm.com/

Prashanth K (3):
  usb: dwc3: Remove of dep->regs
  usb: dwc3: Add dwc pointer to dwc3_readl/writel
  usb: dwc3: Log dwc3 instance name in traces

 drivers/usb/dwc3/core.c    | 200 +++++++++++++++++++------------------
 drivers/usb/dwc3/core.h    |  12 +--
 drivers/usb/dwc3/debugfs.c |  44 ++++----
 drivers/usb/dwc3/drd.c     |  76 +++++++-------
 drivers/usb/dwc3/ep0.c     |  22 ++--
 drivers/usb/dwc3/gadget.c  | 164 +++++++++++++++---------------
 drivers/usb/dwc3/gadget.h  |   4 +-
 drivers/usb/dwc3/io.h      |  11 +-
 drivers/usb/dwc3/trace.h   |  88 ++++++++++------
 drivers/usb/dwc3/ulpi.c    |  10 +-
 10 files changed, 328 insertions(+), 303 deletions(-)

-- 
2.34.1

On Mon, Jan 05, 2026 at 05:23:22PM +0530, Prashanth K wrote:
> When multiple DWC3 controllers are being used, trace events from
> different instances get mixed up making debugging difficult as
> there's no way to distinguish which instance generated the trace.
> 
> Hence append the controller base address into ftrace. This needs
> the following reworks which is addressed using this patch series.
> 
>   1. Removal of dep->regs and use dwc->regs everywhere
>   2. Use dwc pointer in all dwc3_readl/writel()
>   3. Adding the base addr in traces.
> 
> Changes in v2:
> - Avoid using macros for dwc3_readl/writel()
> - Use base address intraces instead of dev name.

Wait, why change this?  The dev name is what you should care about.
"base address" doesn't make much sense as this is on a lot of different
busses, right?

thanks,

greg k-h

Hi Greg,

On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> On Mon, Jan 05, 2026 at 05:23:22PM +0530, Prashanth K wrote:
> > When multiple DWC3 controllers are being used, trace events from
> > different instances get mixed up making debugging difficult as
> > there's no way to distinguish which instance generated the trace.
> > 
> > Hence append the controller base address into ftrace. This needs
> > the following reworks which is addressed using this patch series.
> > 
> >   1. Removal of dep->regs and use dwc->regs everywhere
> >   2. Use dwc pointer in all dwc3_readl/writel()
> >   3. Adding the base addr in traces.
> > 
> > Changes in v2:
> > - Avoid using macros for dwc3_readl/writel()
> > - Use base address intraces instead of dev name.
> 
> Wait, why change this?  The dev name is what you should care about.
> "base address" doesn't make much sense as this is on a lot of different
> busses, right?
> 

I asked Prashanth to do so. The reason is because the device name is not
consistent and not obvious for different busses. For example, for PCI
devices, the device name may be in a form of "dwc3.N.auto". If we only
have access to the traces and not the testing setup (which often is the
case), it's difficult to tell which is which. Also, very often the
consumer of the traces is also the hardware validation engineer, and
IMO, it's more understandable reading base address than device name.

BR,
Thinh

On Mon, Jan 05, 2026 at 04:11:50PM +0000, Thinh Nguyen wrote:
> Hi Greg,
> 
> On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > On Mon, Jan 05, 2026 at 05:23:22PM +0530, Prashanth K wrote:
> > > When multiple DWC3 controllers are being used, trace events from
> > > different instances get mixed up making debugging difficult as
> > > there's no way to distinguish which instance generated the trace.
> > > 
> > > Hence append the controller base address into ftrace. This needs
> > > the following reworks which is addressed using this patch series.
> > > 
> > >   1. Removal of dep->regs and use dwc->regs everywhere
> > >   2. Use dwc pointer in all dwc3_readl/writel()
> > >   3. Adding the base addr in traces.
> > > 
> > > Changes in v2:
> > > - Avoid using macros for dwc3_readl/writel()
> > > - Use base address intraces instead of dev name.
> > 
> > Wait, why change this?  The dev name is what you should care about.
> > "base address" doesn't make much sense as this is on a lot of different
> > busses, right?
> > 
> 
> I asked Prashanth to do so. The reason is because the device name is not
> consistent and not obvious for different busses. For example, for PCI
> devices, the device name may be in a form of "dwc3.N.auto". If we only
> have access to the traces and not the testing setup (which often is the
> case), it's difficult to tell which is which. Also, very often the
> consumer of the traces is also the hardware validation engineer, and
> IMO, it's more understandable reading base address than device name.

But all you need to know is "this is different than the other one", you
don't "need" the io address, right?  And if you really did, just add
that to the trace as well _when_ you actually need it.

device name is how Linux handles devices, please use that otherwise it
just gets confusing for everyone in the end (hint, teach the hardware
engineer what it means.)

thanks,

greg k-h

On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> On Mon, Jan 05, 2026 at 04:11:50PM +0000, Thinh Nguyen wrote:
> > Hi Greg,
> > 
> > On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 05, 2026 at 05:23:22PM +0530, Prashanth K wrote:
> > > > When multiple DWC3 controllers are being used, trace events from
> > > > different instances get mixed up making debugging difficult as
> > > > there's no way to distinguish which instance generated the trace.
> > > > 
> > > > Hence append the controller base address into ftrace. This needs
> > > > the following reworks which is addressed using this patch series.
> > > > 
> > > >   1. Removal of dep->regs and use dwc->regs everywhere
> > > >   2. Use dwc pointer in all dwc3_readl/writel()
> > > >   3. Adding the base addr in traces.
> > > > 
> > > > Changes in v2:
> > > > - Avoid using macros for dwc3_readl/writel()
> > > > - Use base address intraces instead of dev name.
> > > 
> > > Wait, why change this?  The dev name is what you should care about.
> > > "base address" doesn't make much sense as this is on a lot of different
> > > busses, right?
> > > 
> > 
> > I asked Prashanth to do so. The reason is because the device name is not
> > consistent and not obvious for different busses. For example, for PCI
> > devices, the device name may be in a form of "dwc3.N.auto". If we only
> > have access to the traces and not the testing setup (which often is the
> > case), it's difficult to tell which is which. Also, very often the
> > consumer of the traces is also the hardware validation engineer, and
> > IMO, it's more understandable reading base address than device name.
> 
> But all you need to know is "this is different than the other one", you
> don't "need" the io address, right?  And if you really did, just add
> that to the trace as well _when_ you actually need it.

The base address preserves that context to know which instance is which.
If we have the base address, do we still need the device name?

> 
> device name is how Linux handles devices, please use that otherwise it
> just gets confusing for everyone in the end (hint, teach the hardware
> engineer what it means.)
> 

I'm not suggesting to change how we use the device name in term of how
Linux handle devices. This is for the trace event prints specific to
dwc3. The base address carries the additional context which the device
name may not. We should not be confused in the beginning since we are
not replacing any old device name print. There's none to begin with.
We're just adding new context to the trace event.

BR,
Thinh

On Mon, Jan 05, 2026 at 05:01:00PM +0000, Thinh Nguyen wrote:
> On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > On Mon, Jan 05, 2026 at 04:11:50PM +0000, Thinh Nguyen wrote:
> > > Hi Greg,
> > > 
> > > On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 05, 2026 at 05:23:22PM +0530, Prashanth K wrote:
> > > > > When multiple DWC3 controllers are being used, trace events from
> > > > > different instances get mixed up making debugging difficult as
> > > > > there's no way to distinguish which instance generated the trace.
> > > > > 
> > > > > Hence append the controller base address into ftrace. This needs
> > > > > the following reworks which is addressed using this patch series.
> > > > > 
> > > > >   1. Removal of dep->regs and use dwc->regs everywhere
> > > > >   2. Use dwc pointer in all dwc3_readl/writel()
> > > > >   3. Adding the base addr in traces.
> > > > > 
> > > > > Changes in v2:
> > > > > - Avoid using macros for dwc3_readl/writel()
> > > > > - Use base address intraces instead of dev name.
> > > > 
> > > > Wait, why change this?  The dev name is what you should care about.
> > > > "base address" doesn't make much sense as this is on a lot of different
> > > > busses, right?
> > > > 
> > > 
> > > I asked Prashanth to do so. The reason is because the device name is not
> > > consistent and not obvious for different busses. For example, for PCI
> > > devices, the device name may be in a form of "dwc3.N.auto". If we only
> > > have access to the traces and not the testing setup (which often is the
> > > case), it's difficult to tell which is which. Also, very often the
> > > consumer of the traces is also the hardware validation engineer, and
> > > IMO, it's more understandable reading base address than device name.
> > 
> > But all you need to know is "this is different than the other one", you
> > don't "need" the io address, right?  And if you really did, just add
> > that to the trace as well _when_ you actually need it.
> 
> The base address preserves that context to know which instance is which.
> If we have the base address, do we still need the device name?

If you have only the "base address", how do you know which device is which?

thanks,

greg k-h

On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> On Mon, Jan 05, 2026 at 05:01:00PM +0000, Thinh Nguyen wrote:
> > On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 05, 2026 at 04:11:50PM +0000, Thinh Nguyen wrote:
> > > > Hi Greg,
> > > > 
> > > > On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > > > > On Mon, Jan 05, 2026 at 05:23:22PM +0530, Prashanth K wrote:
> > > > > > When multiple DWC3 controllers are being used, trace events from
> > > > > > different instances get mixed up making debugging difficult as
> > > > > > there's no way to distinguish which instance generated the trace.
> > > > > > 
> > > > > > Hence append the controller base address into ftrace. This needs
> > > > > > the following reworks which is addressed using this patch series.
> > > > > > 
> > > > > >   1. Removal of dep->regs and use dwc->regs everywhere
> > > > > >   2. Use dwc pointer in all dwc3_readl/writel()
> > > > > >   3. Adding the base addr in traces.
> > > > > > 
> > > > > > Changes in v2:
> > > > > > - Avoid using macros for dwc3_readl/writel()
> > > > > > - Use base address intraces instead of dev name.
> > > > > 
> > > > > Wait, why change this?  The dev name is what you should care about.
> > > > > "base address" doesn't make much sense as this is on a lot of different
> > > > > busses, right?
> > > > > 
> > > > 
> > > > I asked Prashanth to do so. The reason is because the device name is not
> > > > consistent and not obvious for different busses. For example, for PCI
> > > > devices, the device name may be in a form of "dwc3.N.auto". If we only
> > > > have access to the traces and not the testing setup (which often is the
> > > > case), it's difficult to tell which is which. Also, very often the
> > > > consumer of the traces is also the hardware validation engineer, and
> > > > IMO, it's more understandable reading base address than device name.
> > > 
> > > But all you need to know is "this is different than the other one", you
> > > don't "need" the io address, right?  And if you really did, just add
> > > that to the trace as well _when_ you actually need it.
> > 
> > The base address preserves that context to know which instance is which.
> > If we have the base address, do we still need the device name?
> 
> If you have only the "base address", how do you know which device is which?
> 

By association with the design layout, pci configuration space, device
tree, etc.

The inclusion of base address is helpful when matching along with other
traces such as internal signals or reading pcie traffic traces. They
capture IO access which includes the base address.

Of course, we can also request whoever provides the tracepoints to note
the device name and base address associates with it, then parse of the
tracepoints afterward... an extra step I can potenially skip if the
tracepoints are simple enough.

BR,
Thinh

On Mon, Jan 05, 2026 at 09:16:12PM +0000, Thinh Nguyen wrote:
> On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > On Mon, Jan 05, 2026 at 05:01:00PM +0000, Thinh Nguyen wrote:
> > > On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 05, 2026 at 04:11:50PM +0000, Thinh Nguyen wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > On Mon, Jan 05, 2026, Greg Kroah-Hartman wrote:
> > > > > > On Mon, Jan 05, 2026 at 05:23:22PM +0530, Prashanth K wrote:
> > > > > > > When multiple DWC3 controllers are being used, trace events from
> > > > > > > different instances get mixed up making debugging difficult as
> > > > > > > there's no way to distinguish which instance generated the trace.
> > > > > > > 
> > > > > > > Hence append the controller base address into ftrace. This needs
> > > > > > > the following reworks which is addressed using this patch series.
> > > > > > > 
> > > > > > >   1. Removal of dep->regs and use dwc->regs everywhere
> > > > > > >   2. Use dwc pointer in all dwc3_readl/writel()
> > > > > > >   3. Adding the base addr in traces.
> > > > > > > 
> > > > > > > Changes in v2:
> > > > > > > - Avoid using macros for dwc3_readl/writel()
> > > > > > > - Use base address intraces instead of dev name.
> > > > > > 
> > > > > > Wait, why change this?  The dev name is what you should care about.
> > > > > > "base address" doesn't make much sense as this is on a lot of different
> > > > > > busses, right?
> > > > > > 
> > > > > 
> > > > > I asked Prashanth to do so. The reason is because the device name is not
> > > > > consistent and not obvious for different busses. For example, for PCI
> > > > > devices, the device name may be in a form of "dwc3.N.auto". If we only
> > > > > have access to the traces and not the testing setup (which often is the
> > > > > case), it's difficult to tell which is which. Also, very often the
> > > > > consumer of the traces is also the hardware validation engineer, and
> > > > > IMO, it's more understandable reading base address than device name.
> > > > 
> > > > But all you need to know is "this is different than the other one", you
> > > > don't "need" the io address, right?  And if you really did, just add
> > > > that to the trace as well _when_ you actually need it.
> > > 
> > > The base address preserves that context to know which instance is which.
> > > If we have the base address, do we still need the device name?
> > 
> > If you have only the "base address", how do you know which device is which?
> > 
> 
> By association with the design layout, pci configuration space, device
> tree, etc.
> 
> The inclusion of base address is helpful when matching along with other
> traces such as internal signals or reading pcie traffic traces. They
> capture IO access which includes the base address.
> 
> Of course, we can also request whoever provides the tracepoints to note
> the device name and base address associates with it, then parse of the
> tracepoints afterward... an extra step I can potenially skip if the
> tracepoints are simple enough.

Ok, as you will be the one having to intrepret these, I'll trust you
that they are providing enough information for you to be able to debug
things :)

thanks,

greg k-h