[PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Stepan Moskovchenko]

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.

Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
 Documentation/printk-formats.txt |   13 ++++++++++---
 lib/vsprintf.c                   |    7 +++++++
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8ffb274..dbc977b 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -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);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 39c99fe..9b02a71 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -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

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Andy Shevchenko]

On Mon, 2013-01-21 at 21:47 -0800, Stepan Moskovchenko wrote: 
> 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.
> 
> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
> ---
>  Documentation/printk-formats.txt |   13 ++++++++++---
>  lib/vsprintf.c                   |    7 +++++++
>  2 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 8ffb274..dbc977b 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -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.,

resource_size_t is a typedef of phys_addr_t.

Probably you should mention that your change related to the phys_addr_t
*and* derivatives.

> +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);
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 39c99fe..9b02a71 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -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
> 

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Joe Perches]

On Tue, 2013-01-22 at 09:29 +0200, Andy Shevchenko wrote:
> On Mon, 2013-01-21 at 21:47 -0800, Stepan Moskovchenko wrote: 
> > 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.
[]
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
>  @@ -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;

I believe this should be:

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

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Stepan Moskovchenko]

On 1/21/2013 11:52 PM, Joe Perches wrote:
> 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

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Geert Uytterhoeven]

On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
<stepanm@codeaurora.org> wrote:
> 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.

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 -- geert@linux-m68k.org

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

[PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Stepan Moskovchenko]

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.

Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
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(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8ffb274..e8a6aa4 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -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);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 39c99fe..6e62c3f 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -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

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Joe Perches]

On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
> <stepanm@codeaurora.org> wrote:
> > 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.
> 
> I'm not so sure it's a good idea to start using %p for integer types.

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

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Stepan Moskovchenko]

> On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote:
>> On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
>> <stepanm@codeaurora.org> wrote:
>> > 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.
>>
>> I'm not so sure it's a good idea to start using %p for integer types.
>
> 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

Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Andrew Morton]

On Tue, 22 Jan 2013 16:14:53 -0800
Stepan Moskovchenko <stepanm@codeaurora.org> wrote:

> 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.

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.

Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Rob Landley]

On 01/22/2013 06:14:53 PM, Stepan Moskovchenko wrote:
> 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.
> 
> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>

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

Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Rob Landley]

On 01/22/2013 06:14:53 PM, Stepan Moskovchenko wrote:
> 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.
> 
> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>

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

Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types

[Geert Uytterhoeven]

Hi Rob,

On Thu, Feb 7, 2013 at 5:39 AM, Rob Landley <rob@landley.net> wrote:
> On 01/22/2013 06:14:53 PM, Stepan Moskovchenko wrote:
>> 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.
>>
>> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
>
>
> 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?

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 -- geert@linux-m68k.org

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