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

arch/arm/plat-omap/sram.c +1 -1

index a3f50b3..7857146 100644
@@ -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;
 		}
 	}

Quoted 14 lines · Santosh Shilimkar

arch/arm/plat-omap/sram.c +1 -1

index a3f50b3..7857146 100644
@@ -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;
  		}
  	}

arch/arm/plat-omap/sram.c static void __init omap_map_sram(void) · line 227

Quoted 8 lines

arch/arm/plat-omap/sram.c +1 -1

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

On 4/4/2011 2:42 PM, Russell King - ARM Linux wrote:

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 <[email protected]>
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 <[email protected]>

---
 arch/arm/plat-omap/sram.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

arch/arm/plat-omap/sram.c +5 -5

index a3f50b3..6af3d0b 100644
@@ -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

This looks much better.

Acked-by Russell King <[email protected]>

It looks like Tony hasn't taken it... Tony, are you going to handle this patch?

Quoted 7 lines · Russell King - ARM Linux

This looks much better.

Acked-by Russell King <[email protected]>

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.