Re: [PATCH v2 3/3] usb: dwc3: Log dwc3 instance name in traces

[Prashanth K <prashanth.k@oss.qualcomm.com>]

On 1/7/2026 12:10 PM, Greg Kroah-Hartman wrote:
> On Wed, Jan 07, 2026 at 11:33:11AM +0530, Prashanth K wrote:
>> On 1/6/2026 3:28 PM, Greg Kroah-Hartman wrote:
>> +	snprintf(dwc->base_addr, sizeof(dwc->base_addr), "%08llx",
>> +		 (u64)res->start);
>>
>>> And are you _sure_ it is ok to expose that to userspace?
>>>
>> yes, because it's already part of devname in most cases.
> 
As Thinh suggested PCI based devices has different devname style,  which
is difficult to map with correct controller instance from just trace logs.

> Ah, so then why do you really need this?  :)
> 
>>>> +
>>>>  	if (dev->of_node) {
>>>>  		struct device_node *parent = of_get_parent(dev->of_node);
>>>>  
>>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>>> index 23188b910528..c16e47273ea0 100644
>>>> --- a/drivers/usb/dwc3/core.h
>>>> +++ b/drivers/usb/dwc3/core.h
>>>> @@ -1178,6 +1178,7 @@ struct dwc3_glue_ops {
>>>>   * @wakeup_pending_funcs: Indicates whether any interface has requested for
>>>>   *			 function wakeup in bitmap format where bit position
>>>>   *			 represents interface_id.
>>>> + * @base_addr: The HW base address of DWC3 controller.
>>>
>>> You already have this pointer to the resource in dwc3 somewhere, so why
>>> are you storing this as a char string and not just always using the
>>> "real" resource instead?
>>>
>> No Greg, dwc3 struct doesn't have the resource pointer, but has res for
>> xhci.
> 
> That resource has to be somewhere in the dwc3 structure, otherwise how
> does the driver know how to talk to the device in the end?  Or is that
> just happening deep in the dwc3-platform-specific-code?  And if so,
> doesn't that imply that you can't just rely on a single resource for
> this "address" as you don't know what the platform really does to talk
> to the device?
> 
It does have the iomapped resource (stored in dwc3 struct), but doesn't
have the actual physical address.

> So this leads me back to the "just use the device name" argument.  Don't
> try to encode a platform-type-thing into the name for everyone to be
> using as that's just not going to work well.  But if you totally insist
> on it, please name this something else, as that's not what this really
> is (i.e. "base_addr" is not correct.)
> 
Sorry, I guess there's a confusion here.
We are trying to print the physical address thats coming from DT/ACPI
(reg property). We are not adding the iomem/virtual address here.
I'll rename/document it for better clarity.

Regards,
Prashanth K