linux-mips
[Top] [All Lists]

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

To: macro@linux-mips.org
Subject: Re: [PATCH] Workaround for a sparse warning in include/asm-mips/io.h
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Wed, 11 Jul 2007 23:54:20 +0900 (JST)
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <Pine.LNX.4.64N.0707111516250.26459@blysk.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20070711.231200.05599385.anemo@mba.ocn.ne.jp> <Pine.LNX.4.64N.0707111516250.26459@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 11 Jul 2007 15:28:19 +0100 (BST), "Maciej W. Rozycki" 
<macro@linux-mips.org> wrote:
>  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.

Yes, adding 'L' to KSEG1 is another way to silence the warnings.  But
I just thought it was a bit intrusive.  And I'm not sure all code are
OK if KSEG1 is 'signed' ...

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

I see the warnings on 32-bit qemu kernel.  drivers/serial/8250.c,
lib/devres.c, etc.

I think sparse complains on casting to "void __iomem *" from "int".
It looks sparse accepts casting from "long".

---
Atsushi Nemoto

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