OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'

Commit Message

Santosh Shilimkar April 4, 2011, 9:47 a.m. UTC

On 4/4/2011 2:42 PM, Russell King - ARM Linux wrote:
> On Mon, Apr 04, 2011 at 02:34:56PM +0530, Santosh Shilimkar wrote:
>> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
>> index a3f50b3..7857146 100644
>> --- a/arch/arm/plat-omap/sram.c
>> +++ b/arch/arm/plat-omap/sram.c
>> @@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
>>   		else if (cpu_is_omap1611())
>>   			omap_sram_size = SZ_256K;
>>   		else {
>> -			printk(KERN_ERR "Could not detect SRAM size\n");
>> +			pr_err("Could not detect SRAM size\n");
>>   			omap_sram_size = 0x4000;
>>   		}
>>   	}
>> @@ -221,7 +221,7 @@ static void __init omap_map_sram(void)
>>   	omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
>>   	iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
>>
>> -	printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
>> +	pr_info("SRAM: Mapped pa 0x%08x to va 0x%08lx size: 0x%lx\n",
>>   	__pfn_to_phys(omap_sram_io_desc[0].pfn),
>>   	omap_sram_io_desc[0].virtual,
>>   	       omap_sram_io_desc[0].length);
>
> This is wrong.
>
> I guess this is a consequence of using phys_addr_t rather than explicitly
> 'unsigned long' for physical addresses, which ends up as u32, which in
> turn is 'unsigned int' not 'unsigned long'.
>
> In any case, these warnings are telling us what needs to be fixed for
> large physical addresses.  The way that we've sorted this in the generic
> ARM code is to use 0x%08llx, and casting the physical address to
> 'unsigned long long'.  That gives consistent arguments without printing
> excessive zeros at the start of an address.
Thanks for pointing out this. I see Will's commit on this
one "29a38193"
Here is the updated patch as you suggested.

 From 4d8d4e5c99c1477a8cb04b525ff5a2d93bbdacfd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <[e-mail]>
Date: Mon, 4 Apr 2011 14:20:08 +0530
Subject: [PATCH] OMAP: SRAM: Fix warning: format '%08lx' expects type 
'long unsigned int'

Fix below build warning.

  CC	arch/arm/plat-omap/sram.o
	arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
	arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
	type 'long unsigned int', but argument 2 has type 'unsigned int'

While at this, convert SRAM printk(* "") to pr_*("").

Signed-off-by: Santosh Shilimkar <[e-mail]>
---
  arch/arm/plat-omap/sram.c |   12 ++++++------
  1 files changed, 6 insertions(+), 6 deletions(-)

Comments

Tony Lindgren May 3, 2011, 10:55 a.m. UTC | #1

* Russell King - ARM Linux <[e-mail]> [110428 07:06]:
> 
> This looks much better.
> 
> Acked-by: Russell King <[e-mail]>
> 
> It looks like Tony hasn't taken it...  Tony, are you going to handle
> this patch?

I can add it into my devel-cleanup branch for next merge window
assuming it won't conflict with your sram changes. If there's a
conflict, then you can take it.

I'd rather not merge it in the -rc cycle this late as it's not
in the oopses or major regressions category.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren May 31, 2011, 10:23 a.m. UTC | #2

* Tony Lindgren <[e-mail]> [110503 03:52]:
> * Russell King - ARM Linux <[e-mail]> [110428 07:06]:
> > 
> > This looks much better.
> > 
> > Acked-by: Russell King <[e-mail]>
> > 
> > It looks like Tony hasn't taken it...  Tony, are you going to handle
> > this patch?
> 
> I can add it into my devel-cleanup branch for next merge window
> assuming it won't conflict with your sram changes. If there's a
> conflict, then you can take it.
> 
> I'd rather not merge it in the -rc cycle this late as it's not
> in the oopses or major regressions category.

Got this one finally queued as a fix.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..6af3d0b 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@  static void __init omap_detect_sram(void)
  		else if (cpu_is_omap1611())
  			omap_sram_size = SZ_256K;
  		else {
-			printk(KERN_ERR "Could not detect SRAM size\n");
+			pr_err("Could not detect SRAM size\n");
  			omap_sram_size = 0x4000;
  		}
  	}
@@ -221,10 +221,10 @@  static void __init omap_map_sram(void)
  	omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
  	iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));

-	printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
-	__pfn_to_phys(omap_sram_io_desc[0].pfn),
-	omap_sram_io_desc[0].virtual,
-	       omap_sram_io_desc[0].length);
+	pr_info("SRAM: Mapped pa 0x%08llx to va 0x%08lx size: 0x%lx\n",
+		(long long) __pfn_to_phys(omap_sram_io_desc[0].pfn),
+		omap_sram_io_desc[0].virtual,
+		omap_sram_io_desc[0].length);

  	/*
  	 * Normally devicemaps_init() would flush caches and tlb after
@@ -252,7 +252,7 @@  static void __init omap_map_sram(void)
  void *omap_sram_push_address(unsigned long size)
  {
  	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
+		pr_err("Not enough space in SRAM\n");
  		return NULL;
  	}