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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2026010747-darkroom-peso-24fb@gregkh>
Date: Wed, 7 Jan 2026 07:40:36 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Prashanth K <prashanth.k@....qualcomm.com>
Cc: Thinh Nguyen <Thinh.Nguyen@...opsys.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] usb: dwc3: Log dwc3 instance name in traces

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.

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?

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.)

thanks,

greg k-h