Re: [PATCH 2/7] usb: xhci: use '%pad' specifier for DMA address printing

[Michal Pecio <michal.pecio@gmail.com>]

On Tue, 9 Sep 2025 14:29:20 +0300, Andy Shevchenko wrote:
> On Tue, Sep 09, 2025 at 11:59:49AM +0200, Michal Pecio wrote:
> > Old %llx with (long long) cast also prints it corretly.  
> 
> Not really. It prints unnecessary long values on 32-bit machines
> making an impression that something works somewhere in 64-bit
> address space.

The %016llx format you are alluding to is used in two error messages
actually seen by users, that's an issue. My crazy personal preference
would be %08llx, but I concede it's unprofessional, so %pad it seems.

But it's the exact function I have shown where three otherwise useless
dma_addr_t are introduced to get around pass-by-reference limitation.

Maybe there would be a way to limit their scope at least?

In these messages, all values are indeed known-good DMA pointers or
truncated to dma_addr_t by the time they are printed (but ep_trb_dma
is truncated silently, not ideal).


Elsewhere, HW-originated DMA pointers are handled as u64 and dynamic-
debugged as %08llx. Call it messy or sloppy, but it's automagic and
convenient - with no leading zeros, significant digits stand out more.
A nonzero top DWORD on a 32 bit system sticks out like a sore thumb.

The exact same *value* may be handled as dma_addr_t before it passes
through HW and as u64 after it comes out. It would be nice if both
copies looked the same in the log.

> > Secondly, padding is not optional with %pad. Maybe not a big deal, but
> > on 64 bit systems with comparatively little RAM it adds clutter.  
> 
> I don't get this, can you elaborate what's the problem in using _standard_
> way of printing pointers / addresses?

I simply find that leading zeros are distracting and make it harder
to visually scan for equal or similar numbers in a wall of text,
which is what dynamic debug is about.

Regards,
Michal