From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Prashanth K <prashanth.k@oss.qualcomm.com>,
Thinh Nguyen <Thinh.Nguyen@synopsys.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: Wed, 14 Jan 2026 22:54:48 +0000 [thread overview]
Message-ID: <20260114225441.rn3affmwuhfl2z7x@synopsys.com> (raw)
In-Reply-To: <2026011400-monthly-commend-f89b@gregkh>
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.
BR,
Thinh
next prev parent reply other threads:[~2026-01-14 22:55 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 [this message]
2026-01-14 23:54 ` Thinh Nguyen
2026-01-15 6:37 ` Greg Kroah-Hartman
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=20260114225441.rn3affmwuhfl2z7x@synopsys.com \
--to=thinh.nguyen@synopsys.com \
--cc=gregkh@linuxfoundation.org \
--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