Re: [PATCH 7/7] usb: xhci: standardize address format

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

On Wed,  3 Sep 2025 19:01:27 +0200, Niklas Neronin wrote:
> In the xHCI driver, printed hexadecimal values can be ambiguous, making it
> difficult to distinguish between values and addresses. To enhance clarity,
> all DMA addresses are now prefixed with the '@' symbol, ensuring immediate
> recognition as addresses.

Is it really a problem? Which values look like addresses?

Is it important enough to justify merge conflicts on multiple debug
messages when porting patches to stable? There are many inconsistencies
and typose in those messages, but I only clean them up if change is
necessary for other reasons.

> The '@' prefix is removed from '%p' specifiers, as they represent unique
> address IDs rather than actual addresses. The hashing process does not
> preserve any relation between addresses; for instance, if two addresses
> are X bytes apart, their hashed counterparts will not reflect this
> distinction.

Is it really a problem? BTW, you can reboot with 'no_hash_pointers'
to make %p work normally for debugging.

Personally, I do believe that there is a problem: those @ add no real
information and they need to be stripped by scripts or when copying
numbers from logs to calculators. But see comment above.

This problem applies to new cases added by this patch as well.

And what if the kernel starts hashing %pad by default? ;)

> Exceptions to the '@' prefix rule are functions xhci_ring_enqueue_show()
> and xhci_ring_dequeue_show(), which exclusively print to the enqueue and
> dequeue debugfs files, containing only addresses.

So debugfs will also get @ now, except for two files apparently?

Why are those files left out and inconsistent with the rest? If the
answer is "because the @ prefix is annoying and breaks tools" then the
same answer applies to every other debugfs file ;)

I have a script which parses event-ring/trbs and command-ring/trbs to
print commands and their completions together. Others may have other
scripts. They will stop working now. And for what gain?

debugfs is nothing but dumps od xHCI data structures, anyone going
there already knows what those fields are.

> Standardize printing of all 64-bit addresses read from registers, using
> the "0x%llx" specifier.

%#llx is easier to type and less eye sore than 0x%llx.

The 0x prefix is maybe rarely necessary for humans, but useful because
such format is ready to parse by hex-aware calculators or scripts.

Same argument works against @ prefix. Scripting languages, terminals
and text editors can select whole words and we don't need @ included.

> Adding padding is unnecessary and provides no useful information.
> Prefix the value with "0x" to clearly indicate that its a hexadecimal.

Sounds like an argument against converting to %pad in other places?

That being said, I'm not sure if %08llx is truly evil yet.

> $ git grep -n '0x%' | wc -l
> 39796
> $ git grep -n '%#' | wc -l
> 5204

Not sure what is this doing in a commit message?

> Redundant "0x" string prefix is removed from DMA addresses printed
> using the '%pad' specifier, since '%pad' automatically includes the
> "0x" prefix.

Not sure if urgent enough to bother, but makes sense of course.

Regards,
Michal