lib: vsprintf: Add %pa format specifier for phys_addr_t types

Add the %pa format specifier for printing a phys_addr_t type, since the physical address size on some platforms can vary based on build options, regardless of the native integer type.

---
 Documentation/printk-formats.txt |   13 ++++++++++---
 lib/vsprintf.c                   |    7 +++++++
 2 files changed, 17 insertions(+), 3 deletions(-)

index 8ffb274..dbc977b 100644
@@ -53,6 +53,13 @@ Struct Resources:
 	For printing struct resources. The 'R' and 'r' specifiers result in a
 	printed resource with ('R') or without ('r') a decoded flags member.
 
+Physical addresses:
+
+	%pa	0x01234567 or 0x0123456789abcdef
+
+	For printing a phys_addr_t type, which can vary based on build options,
+	regardless of the width of the CPU data path. Passed by reference.
+
 Raw buffer as a hex string:
 	%*ph	00 01 02  ...  3f
 	%*phC	00:01:02: ... :3f

@@ -150,9 +157,9 @@ s64 SHOULD be printed with %lld/%llx, (long long):
 	printk("%lld", (long long)s64_var);
 
 If <type> is dependent on a config option for its size (e.g., sector_t,
-blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
-for its size (e.g., tcflag_t), use a format specifier of its largest
-possible type and explicitly cast to it.  Example:
+blkcnt_t, resource_size_t) or is architecture-dependent for its size (e.g.,
+tcflag_t), use a format specifier of its largest possible type and explicitly
+cast to it.  Example:
 
 	printk("test: sector number/total blocks: %llu/%llu\n",
 		(unsigned long long)sector, (unsigned long long)blockcount);

index 39c99fe..9b02a71 100644
@@ -1022,6 +1022,7 @@ int kptr_restrict __read_mostly;
  *              N no separator
  *            The maximum supported length is 64 bytes of the input. Consider
  *            to use print_hex_dump() for the larger input.
+ * - 'a' For a phys_addr_t type (passed by reference)
  *
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a

@@ -1112,6 +1113,12 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
 			return netdev_feature_string(buf, end, ptr, spec);
 		}
 		break;
+	case 'a':
+		spec.flags |= SPECIAL | SMALL | ZEROPAD;
+		spec.field_width = sizeof(phys_addr_t) * 2;
+		spec.base = 16;
+		return number(buf, end,
+			      (unsigned long long) *((phys_addr_t *)ptr), spec);
 	}
 	spec.flags |= SMALL;
 	if (spec.field_width == -1) {

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[]

[]

I believe this should be:

	spec.field_width = sizeof(phys_addr_t) * 2 + 2;

Ah yes, I believe you are right. I had only added the SPECIAL flag after writing this. Will fix in v2.

 The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 hosted by The Linux Foundation

I'm not so sure it's a good idea to start using %p for integer types. For structures like MAC addresses, it makes life easier.

%p offers very minimal support from the compiler for checking the argument type. At least with casting to "unsigned long long" and using %llu not much can go wrong if there are no compiler warnings.

Also variables holding MAC address typically don't change, while there's been lots of churn in variables changing type from unsigned long to phys_addr_t or unsigned long long or void *. Without help of the compiler to catch incorrect format
specifiers, it will become much more difficult to get and keep all of them correct.

Just my two (euro)cents...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

It would also require that some automatic variables that could otherwise be used in registers be put on the stack.

When calling something like printk on a variable, is that really a big concern in the grand scheme of things? On a system with a 32-bit phys_addr_t type, how does the overhead of having to put the variable on the stack compare to the overhead needed to cast to an unsigned long long and emit the eight extra '0' characters when printing a formatted physical address? If allocation efficiency is a big concern for a particular code path, the caller is always free to continue to cast to unsigned long long and use %llu, if they don't mind extra padding where phys_addr_t is smaller than a long long. But considering this is primarily meant to be used by printk during initialization / debug / error handling paths, there will be plenty of other overhead involved in producing log output.

As far as type safety is concerned, the %p specifier is already willing to accept pointers to all sorts of things which it is powerless to check, and it is up to the caller to do the right thing.

Printing out a physical address is a pretty reasonable thing for a driver to do in an init or debug path. It is conceivable that the same driver may be used on a system with 32-bit ore >32-bit physical address types. With something like ARM LPAE, it is even possible for the same system to use 32-bit and >32-bit addressing based strictly on build options, while still using the same drivers, meaning that the drivers would need to deal with phys_addr_t being of variable size. It also seems like a potential bit of extra overhead is not worth the ugliness of casting each phys_addr_t to an unsigned long long and printing it as a 64-bit type regardless of the actual number of address bits available. If a driver is really concerned about efficiency of its init paths, it is free to continue using %llu, or better yet, cut down on the amount of log spam these paths generate.

Steve

Add the %pa format specifier for printing a phys_addr_t type and its derivative types (such as resource_size_t), since the physical address size on some platforms can vary based on build options, regardless of the native integer type.

---
v2: - Update field width to make room for the '0x' prefix
- Update documentation to include derivative types

 Documentation/printk-formats.txt |   14 +++++++++++---
 lib/vsprintf.c                   |    7 +++++++
 2 files changed, 18 insertions(+), 3 deletions(-)

index 8ffb274..e8a6aa4 100644
@@ -53,6 +53,14 @@ Struct Resources:
 	For printing struct resources. The 'R' and 'r' specifiers result in a
 	printed resource with ('R') or without ('r') a decoded flags member.
 
+Physical addresses:
+
+	%pa	0x01234567 or 0x0123456789abcdef
+
+	For printing a phys_addr_t type (and its derivatives, such as
+	resource_size_t) which can vary based on build options, regardless of
+	the width of the CPU data path. Passed by reference.
+
 Raw buffer as a hex string:
 	%*ph	00 01 02  ...  3f
 	%*phC	00:01:02: ... :3f

@@ -150,9 +158,9 @@ s64 SHOULD be printed with %lld/%llx, (long long):
 	printk("%lld", (long long)s64_var);
 
 If <type> is dependent on a config option for its size (e.g., sector_t,
-blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
-for its size (e.g., tcflag_t), use a format specifier of its largest
-possible type and explicitly cast to it.  Example:
+blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
+format specifier of its largest possible type and explicitly cast to it.
+Example:
 
 	printk("test: sector number/total blocks: %llu/%llu\n",
 		(unsigned long long)sector, (unsigned long long)blockcount);

index 39c99fe..6e62c3f 100644
@@ -1022,6 +1022,7 @@ int kptr_restrict __read_mostly;
  *              N no separator
  *            The maximum supported length is 64 bytes of the input. Consider
  *            to use print_hex_dump() for the larger input.
+ * - 'a' For a phys_addr_t type and its derivative types (passed by reference)
  *
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a

@@ -1112,6 +1113,12 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
 			return netdev_feature_string(buf, end, ptr, spec);
 		}
 		break;
+	case 'a':
+		spec.flags |= SPECIAL | SMALL | ZEROPAD;
+		spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+		spec.base = 16;
+		return number(buf, end,
+			      (unsigned long long) *((phys_addr_t *)ptr), spec);
 	}
 	spec.flags |= SMALL;
 	if (spec.field_width == -1) {

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Looks sane.

Now, how do we hunt down the existing callsites which can be converted to use this?

It would be nice to change at least a few of them right now, so your patch gets tested. Common x86 ones, ideally.

Ok, I know I'm late to the party, but doesn't LP64 apply here? Are we really capable of building on a target where "long" and "pointer" are different sizes? Last I checked the kernel was full of that assumption because there was an actual standard and we demanded that the compiler building us comply with it, just like MacOS X and the BSDs do:

Standard:
http://www.unix.org/whitepapers/64bit.html

Rationale:
http://www.unix.org/version2/whatsnew/lp64_wp.html

Insane legacy reasons Windows decided to be "special":
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Thus "unsigned long" should by definition be big enough. Using unsigned long long means you're doing 64 bit math on 32 bit targets for no apparent reason.

What did I miss?

Rob

Hi Rob,

This is about phys_addr_t and resource_size_t, which are _physical_ addresses, not virtual adresses. Virtual addresses are still 32-bit, so unsigned long is fine for them.

But these days several CPUs have 36-bit physical addresses, which don't fit in unsigned long.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds