[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260114235357.zueeylekf4lfdq4g@synopsys.com>
Date: Wed, 14 Jan 2026 23:54:03 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Prashanth K <prashanth.k@....qualcomm.com>,
Greg Kroah-Hartman
<gregkh@...uxfoundation.org>
CC: "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 3/3] usb: dwc3: Log dwc3 address in traces
On Wed, Jan 14, 2026, Thinh Nguyen wrote:
> On Wed, Jan 14, 2026, Greg Kroah-Hartman wrote:
> > On Wed, Jan 14, 2026 at 03:37:48PM +0530, Prashanth K wrote:
> > > + * @address: Cached lower 32-bit base address to be used for logging.
> >
> > Why are 32bits enough / ok? Why not use the full 64 that you really
> > have? What happens if you have 2 devices with just the upper 32 bits
> > different?
> >
> > This is a resource value, so why not use the proper type for it?
> >
>
> This is only intented to be used for logging, so I suggested to use u32.
> I want to avoid treating this struct member as a phys_addr_t where it
> may be misused.
>
> As for the reason to capture only the lower 32-bit, it's just base on
> what I've seen so far. That I have not seen designs where the 2 or more
> instances are placed that far apart and share the same lower 32-bit.
> It's a bit nicer to shorten the address print at the start of a
> tracepoint. But if it's insufficient, there's no problem with using
> 64-bit.
>
Or we can just remove this and print the address from
dwc->xhci_resources[0].start.
BR,
Thinh
Powered by blists - more mailing lists