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
