mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Prashanth K <prashanth.k@oss.qualcomm.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: Log dwc3 instance name in traces
Date: Thu, 4 Sep 2025 14:39:26 +0530	[thread overview]
Message-ID: <745a2b9c-078d-45eb-97a7-3a27a4bc5191@oss.qualcomm.com> (raw)
In-Reply-To: <20250904000003.b4j7fnucronjf6ej@synopsys.com>



On 9/4/2025 5:30 AM, Thinh Nguyen wrote:
> On Wed, Sep 03, 2025, Prashanth K wrote:
>>
>>
>> On 9/3/2025 5:14 AM, Thinh Nguyen wrote:
>>> On Mon, Sep 01, 2025, Prashanth K wrote:
>>>>
>>>>
>>>> On 8/29/2025 4:18 AM, Thinh Nguyen wrote:
>>>>> Hi,
>>>>>
>>>>> On Mon, Aug 25, 2025, 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.
>>>>>>
>>>>>> Append the device name to trace events to clearly identify the
>>>>>> source instance.
>>>>>
>>>>> Can we print the base address instead of the device name? This will be
>>>>> consistent across different device names, and it will be easier to
>>>>> create filter.
>>>>>
>>>> Did you mean to print the iomem (base address) directly?
>>>> I think using device name is more readable, in most cases device name
>>>> would contain the base address also. Let me know if you are pointing to
>>>> something else.>>
>>>
>>> Yes, I mean the device base address. PCI devices won't have the base
>>> address as part of the device name.
>>>
>> But the base address (void __iomem *base) wouldn't be helpful.
>> Using the base address, i guess we would be able to differentiate the
>> traces when there are multiple instances, but it wouldn't help us
>> identify which controller instance generated which trace.
>>
>> And for PCI devices, i agree that it doesn't have  address in device
>> name, but i think we should be able to identify the correct instance
>> based on the bus/device numbers, right ?
>>
> 
> We may not have the PCI domain numbers if it's a child device as in the
> case of dwc3-pci or dwc3-haps.
> 
> The base address _does_ tell you exactly which device the tracepoints
> correspond to. The device name is inconsistent between different device
> types and only relevant if we have access to the system to know which
> name belongs to which instance.

Yes, I agree that device name would be inconsistent for different for
PCI (and HAPS) devices. But IMO using base address (virtual) would just
make it more harder to read and identify the instance.

Perhaps we can cache the register addr and use it, what do you think?
Here we can at least differentiate the instances based on HW addr.

snprintf(dwc->inst, sizeof(dwc->inst), "0x%08llx", (unsigned long
long)res->start);
dev_info(dwc->dev, "addr:%s\n", dwc->inst);

Output --> [    4.521746] dwc3 a600000.usb: addr:0x0a600000
Regards,
Prashanth K

  reply	other threads:[~2025-09-04  9:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-25 11:44 Prashanth K
2025-08-28 22:48 ` Thinh Nguyen
2025-09-01  9:56   ` Prashanth K
2025-09-02 23:44     ` Thinh Nguyen
2025-09-03  6:52       ` Prashanth K
2025-09-04  0:00         ` Thinh Nguyen
2025-09-04  9:09           ` Prashanth K [this message]
2025-09-04 23:44             ` Thinh Nguyen
2025-09-09  5:00               ` Prashanth K
2025-09-11  1:36                 ` Thinh Nguyen
2025-09-11  4:46                   ` Prashanth K
2025-09-12 21:54                     ` Thinh Nguyen
2025-09-12 23:11                       ` Thinh Nguyen
2025-09-19 10:59                       ` Prashanth K
2025-09-19 21:01                         ` Thinh Nguyen

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=745a2b9c-078d-45eb-97a7-3a27a4bc5191@oss.qualcomm.com \
    --to=prashanth.k@oss.qualcomm.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.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

all inboxes | Powered by JetHome®