From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Prashanth K <prashanth.k@oss.qualcomm.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/3] usb: dwc3: Log dwc3 address in traces
Date: Thu, 15 Jan 2026 07:37:38 +0100 [thread overview]
Message-ID: <2026011500-safehouse-alphabet-3056@gregkh> (raw)
In-Reply-To: <20260114235357.zueeylekf4lfdq4g@synopsys.com>
On Wed, Jan 14, 2026 at 11:54:03PM +0000, Thinh Nguyen wrote:
> 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.
I thought I asked for that a few revisions ago :)
I'd prefer that, instead of saving off a value that you can look up if
you need it.
thanks,
greg k-h
next prev parent reply other threads:[~2026-01-15 6:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 10:07 [PATCH v4 0/3] Add the address in traces Prashanth K
2026-01-14 10:07 ` [PATCH v4 1/3] usb: dwc3: Remove of dep->regs Prashanth K
2026-01-14 10:07 ` [PATCH v4 2/3] usb: dwc3: Add dwc pointer to dwc3_readl/writel Prashanth K
2026-01-14 10:07 ` [PATCH v4 3/3] usb: dwc3: Log dwc3 address in traces Prashanth K
2026-01-14 11:40 ` Greg Kroah-Hartman
2026-01-14 22:54 ` Thinh Nguyen
2026-01-14 23:54 ` Thinh Nguyen
2026-01-15 6:37 ` Greg Kroah-Hartman [this message]
2026-01-15 16:22 ` Thinh Nguyen
2026-01-16 5:37 ` Prashanth K
2026-01-16 17:51 ` Thinh Nguyen
2026-01-19 6:55 ` Prashanth K
2026-01-21 0:10 ` Thinh Nguyen
2026-01-14 11:42 ` Greg Kroah-Hartman
2026-01-14 22:30 ` 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=2026011500-safehouse-alphabet-3056@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=prashanth.k@oss.qualcomm.com \
/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