Compiling 2.6.27-rc5 on 32-bit x86 with CONFIG_RESOURCES_64BIT=n
results in numerous warnings from drivers/pci:
drivers/pci/probe.c:386: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
drivers/pci/probe.c:386: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
drivers/pci/probe.c:398: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
drivers/pci/probe.c:398: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
drivers/pci/probe.c:434: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
drivers/pci/probe.c:434: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'
drivers/pci/setup-bus.c:542: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'
drivers/pci/setup-bus.c:542: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
resource_size_t can be u32 or u64 (see include/linux/types.h) but the printk
formats always say "%llx" which expects u64, resulting in general badness.
This patch fixes it by casting the offending printk parameters to u64.
(I would have preferred to make linux/types.h #define a proper format string
for resource_size_t, like <inttypes.h> does in user-space, but there doesn't
seem to be a precedent for that in the Linux kernel, so I used casts instead.)
The effect of this bug can be seen in this partial diff between a dmesg log
from a vanilla 2.6.27-rc5 and one with the fix applied:
--- dmesg-2.6.27-rc5.bad 2008-08-29 13:50:58.000000000 +0200
+++ dmesg-2.6.27-rc5 2008-08-29 14:09:20.000000000 +0200
@@ -159,16 +159,16 @@
pci 0000:01:00.0: supports D2
pci 0000:01:00.1: supports D1
pci 0000:01:00.1: supports D2
-PCI: bridge 0000:00:01.0 io port: ...
