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

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

On Wed, 10 Sep 2025 11:04:48 +0200, Michal Pecio wrote:
> [13035.022589] xhci_hcd 0000:00:10.0: Stopped on Transfer TRB for slot 1 ep 2
> [13035.022648] xhci_hcd 0000:00:10.0: Removing canceled TD starting at @0x00000000fffae050 (dma) in stream 0 URB ffff88813358a3c0
> [13035.022657] xhci_hcd 0000:00:10.0: Set TR Deq ptr @0x00000000fffae060, cycle 1
> 
> [13035.022662] xhci_hcd 0000:00:10.0: // Ding dong!
> [13035.022666] xhci_hcd 0000:00:10.0: xhci_giveback_invalidated_tds: Keep cancelled URB ffff88813358a3c0 TD as cancel_status is 2
> [13035.022835] xhci_hcd 0000:00:10.0: Successful Set TR Deq Ptr cmd, deq = 0xfffae060

This also illustrates how this series degrades usability by printing
the same DMA twice in different manner:

@0x00000000fffae060	<-- zero padding and @ (?)
         0xfffae060	<-- bare number

It's the exact same number. And this is what everyone looking at this
log wants to know - is the number the same, or is it different?

It doesn't matter what type of variable is storing this number in given
moment. Source code provides this information much more reliably than
type annotations in debug messages which people will break over time.