[PATCH] dmaengine: at_xdmac: Fixed printk format specifier when printing driver information.

Use the correct printk specifier to print the address, otherwise
you get weird information:
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0x(ptrval)
at_xdmac f0004000.dma-controller: 16 channels, mapped at 0x(ptrval)

After the change, the information looks much more informative:
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0xc8892000
at_xdmac f0004000.dma-controller: 16 channels, mapped at 0xc8894000

Signed-off-by: Alexander Shiyan <redacted>
---
 drivers/dma/at_xdmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index ba25c23164e7..a4188046804d 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c

@@ -2409,7 +2409,7 @@ static int at_xdmac_probe(struct platform_device *pdev)
 		goto err_dma_unregister;
 	}
 
-	dev_info(&pdev->dev, "%d channels, mapped at 0x%p\n",
+	dev_info(&pdev->dev, "%d channels, mapped at 0x%px\n",
 		 nr_channels, atxdmac->regs);
 
 	at_xdmac_axi_config(pdev);

-- 
2.39.1

Hi Alexander,

Alexander Shiyan [off-list ref] writes:

Use the correct printk specifier to print the address, otherwise
you get weird information:
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0x(ptrval)
at_xdmac f0004000.dma-controller: 16 channels, mapped at 0x(ptrval)

After the change, the information looks much more informative:
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0xc8892000
at_xdmac f0004000.dma-controller: 16 channels, mapped at 0xc8894000

...

dev_info (i.e. printk) obfuscates kernel pointers by design. This change
would defeat that.

Please refer to the discussion of pointers in
Documentation/core-api/printk-formats.rst for an explanation of the
"(ptrval)" behavior and whether it's appropriate to use %px here:

  Before using %px, consider if using %p is sufficient together with
  enabling the 'no_hash_pointers' kernel parameter during debugging
  sessions.

As well as related discussion in Documentation/process/deprecated.rst:

  %p format specifier
  -------------------
  Traditionally, using "%p" in format strings would lead to regular address
  exposure flaws in dmesg, proc, sysfs, etc. Instead of leaving these to
  be exploitable, all "%p" uses in the kernel are being printed as a hashed
  value, rendering them unusable for addressing. New uses of "%p" should not
  be added to the kernel. For text addresses, using "%pS" is likely better,
  as it produces the more useful symbol name instead. For nearly everything
  else, just do not add "%p" at all.