Re: [PATCH, v2] ARM: omap2: gpmc: fix compilation warning

[Tony Lindgren <tony@atomide.com>]

* Vincent Stehlé <vincent.stehle@laposte.net> [130514 10:26]:
> From: Vincent Stehlé <v-stehle@ti.com>
> 
> Fix the following compilation warning:
> 
>   arch/arm/mach-omap2/gpmc.c: In function 'gpmc_probe_generic_child':
>   arch/arm/mach-omap2/gpmc.c:1477:4: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat]
> 
> Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
> Cc: trivial@kernel.org
> ---
> 
> Tony wrote:
> > You should just change the format for dev_err instead of the casting.
> 
> Hi,
> 
> Sorry for the late answer; it seems this is a bit more complicated after all,
> as res.start can be 32b or 64b in LPAE. The common solution seems to be: cast
> to long long in all cases and print accordingly. Would you like this better?

Oh OK. In this case the GPMC is always within the 32-bit address space.

But considering that similar issue will be there for other code with
LPAE, how about add something generic to arch/arm/include/asm/io.h like:

#define PHYS_ADDR32(x)	((__force u32)(x))
#define PHYS_ADDR64(x)	((__force u64)(x))

Or maybe something like that already exists.

Regards,

Tony

>  arch/arm/mach-omap2/gpmc.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 6c4da12..e74501e 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1473,8 +1473,8 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
>  	 */
>  	ret = gpmc_cs_remap(cs, res.start);
>  	if (ret < 0) {
> -		dev_err(&pdev->dev, "cannot remap GPMC CS %d to 0x%x\n",
> -			cs, res.start);
> +		dev_err(&pdev->dev, "cannot remap GPMC CS %d to 0x%llx\n",
> +			cs, (long long)res.start);
>  		goto err;
>  	}
>  
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html