linux-mips
[Top] [All Lists]

Re: [PATCH] Workaround for a sparse warning in include/asm-mips/io.h

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: [PATCH] Workaround for a sparse warning in include/asm-mips/io.h
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Wed, 11 Jul 2007 15:28:19 +0100 (BST)
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <20070711.231200.05599385.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20070711.231200.05599385.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 11 Jul 2007, Atsushi Nemoto wrote:

> CKSEG1ADDR() returns unsigned int value on 32bit kernel.  Cast it to
> unsigned long to get rid of this warning:
> 
> include2/asm/io.h:215:12: warning: cast adds address space to expression 
> (<asn:2>)
> 
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
> ---
> diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h
> index 12bcc1f..7ba9289 100644
> --- a/include/asm-mips/io.h
> +++ b/include/asm-mips/io.h
> @@ -212,7 +212,8 @@ static inline void __iomem * __ioremap_mode(phys_t 
> offset, unsigned long size,
>                */
>               if (__IS_LOW512(phys_addr) && __IS_LOW512(last_addr) &&
>                   flags == _CACHE_UNCACHED)
> -                     return (void __iomem *)CKSEG1ADDR(phys_addr);
> +                     return (void __iomem *)
> +                             (unsigned long)CKSEG1ADDR(phys_addr);
>       }

 It looks like a bug in sparse.  The result of CKSEG1ADDR() has the same 
size as the pointer.  Perhaps we could append 'L' to the expansion of 
KSEG1 et al, but that should not really matter.

 But -- I have just checked two example calls to this function, one with a 
32-bit configuration and another one with a 64-bit one and sparse did not 
complain.  The cpp expansions of the expression in question are:

return (void *)((((int)(int)(phys_addr)) & 0x1fffffff) | 0xa0000000);

and:

return (void *)((((long int)(int)(phys_addr)) & 0x1fffffff) | 
0xffffffffa0000000L);

respectively, so your cast is definitely redundant in these cases.  What 
sort of configuration are you using?  What's the preprocessor output for 
the problematic case?

  Maciej

<Prev in Thread] Current Thread [Next in Thread>