linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/14] ARM: LPC32XX: Initial architecture header files
Date: Tue, 9 Feb 2010 17:52:23 +0100	[thread overview]
Message-ID: <20100209165223.GA11113@pengutronix.de> (raw)
In-Reply-To: <20100209095934.GA11534@n2100.arm.linux.org.uk>

[Added linux-sparse at vger.kernel.org to Cc:]

On Tue, Feb 09, 2010 at 09:59:34AM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 09, 2010 at 10:31:29AM +0100, Uwe Kleine-K?nig wrote:
> > > +#define io_p2v(x)	((void __iomem *) (unsigned long) IO_ADDRESS(x))
> > Is this cast to unsigned long needed?  AFAIK IO_ADDRESS(x) has
> > type unsigned for x in { 0x0 ... 0xffffffff } (provided that int uses a
> > 32 bit 2s-complement representation).  If unsigned long is really
> > needed, maybe put it into the IO_ADDRESS macro?
> 
> int -> void __iomem * = sparse warning
> unsigned long -> void __iomem * = no sparse warning
Ah, OK, I see.  But IMHO it's a poor reason to add the cast.  Either
the cast is necessary/recommended or sparse is wrong.  In the first case
the reasoning shouldn't have to do with sparse, in the latter sparse
should be fixed.

I found the responsible code in sparse.  It reads:

	static struct symbol *evaluate_cast(struct expression *expr)
	{
		int as1 = 0, as2 = 0;
		...
		ctype = examine_symbol_type(expr->cast_type);
		...
		class1 = classify_type(ctype, &t1);
		...
		if (t1 == &ulong_ctype)
			as1 = -1;
		else if (class1 == TYPE_PTR) {
			examine_pointer_target(t1);
			as1 = t1->ctype.as;
		}
		
		if (t2 == &ulong_ctype)
			as2 = -1;
		else if (class2 == TYPE_PTR) {
			examine_pointer_target(t2);
			as2 = t2->ctype.as;
		}
		...
		if (as1 > 0 && !as2 &&
		    !is_null_pointer_constant(target) && Wcast_to_as)
			warning(expr->pos,
				"cast adds address space to expression (<asn:%d>)", as1);

so it seems to be explicitly allowed to make a pointer in any address
space from an unsigned long, but not from a (signed or unsigned) int.
Unfortunately there is no comment describing why unsigned long is
allowed.

Is this intended?  What is the preferred way to define iomem pointers?

I found the following variants in the kernel[1]

	#define ...	((void __iomem *)(unsigned long)0x12345678)
	#define ...	((void __iomem __force *)0x12345678)
	#define ...	((void __iomem *)0x12345678)

where __iomem is defined as __attribute__((noderef, address_space(2)))
for sparse.

The first variant with the extra cast to unsigned long seems unnecessary
long, the third results in the "cast adds address space to expression"
warning.

So what do you recommend?

Best regards and thanks
Uwe

[1] I only checked a few files, so maybe there are more.
-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  reply	other threads:[~2010-02-09 16:52 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-09  0:11 LPC32XX architecture files (updated v3) wellsk40 at gmail.com
2010-02-09  0:11 ` [PATCH 01/14] ARM: LPC32XX: Initial architecture header files wellsk40 at gmail.com
2010-02-09  9:31   ` Uwe Kleine-König
2010-02-09  9:52     ` Uwe Kleine-König
2010-02-09  9:59     ` Russell King - ARM Linux
2010-02-09 16:52       ` Uwe Kleine-König [this message]
2010-02-09 17:10         ` H Hartley Sweeten
2010-02-09 17:58         ` Russell King - ARM Linux
2010-02-09 19:17     ` Kevin Wells
2010-02-09  0:11 ` [PATCH 02/14] ARM: LPC32XX: Debug and IRQ macros wellsk40 at gmail.com
2010-02-09  9:45   ` Uwe Kleine-König
2010-02-09  0:11 ` [PATCH 03/14] ARM: LPC32XX: Clock driver wellsk40 at gmail.com
2010-02-09 10:39   ` Uwe Kleine-König
2010-02-09 19:18     ` Kevin Wells
2010-02-19  0:42     ` Kevin Wells
2010-02-19  9:21       ` Uwe Kleine-König
2010-02-09  0:11 ` [PATCH 04/14] ARM: LPC32XX: GPIO, timer, and IRQ drivers wellsk40 at gmail.com
2010-02-09 10:58   ` Uwe Kleine-König
2010-02-09  0:11 ` [PATCH 05/14] ARM: LPC32XX: System suspend support wellsk40 at gmail.com
2010-02-09 17:03   ` Uwe Kleine-König
2010-02-09 19:18     ` Kevin Wells
2010-02-14 16:51   ` Pavel Machek
2010-02-14 19:45     ` Russell King - ARM Linux
2010-02-09  0:11 ` [PATCH 06/14] ARM: LPC32XX: Serial support code wellsk40 at gmail.com
2010-02-09  0:11 ` [PATCH 07/14] ARM: LPC32XX: Misc support functions wellsk40 at gmail.com
2010-02-12 20:06   ` Uwe Kleine-König
2010-02-09  0:11 ` [PATCH 08/14] ARM: LPC32XX: Phytec 3250 platform support wellsk40 at gmail.com
2010-02-12 20:08   ` Uwe Kleine-König
2010-02-16 19:43     ` Kevin Wells
2010-02-09  0:11 ` [PATCH 09/14] ARM: LPC32XX: Arch config menu supoport and makefiles wellsk40 at gmail.com
2010-02-09  0:11 ` [PATCH 10/14] ARM: LPC32XX: Default PHY3250 kernel config (ramdisk) wellsk40 at gmail.com
2010-02-09  0:11 ` [PATCH 11/14] ARM: Add support for the LPC32XX arch wellsk40 at gmail.com
2010-02-09  0:11 ` [PATCH 12/14] AMBA: CLCD: LPC32XX register swap in the clcd header file wellsk40 at gmail.com
2010-02-12 14:31   ` Russell King - ARM Linux
2010-02-12 16:32     ` Kevin Wells
2010-02-12 16:41       ` Russell King - ARM Linux
2010-02-16 20:27         ` Kevin Wells
2010-02-18 17:21           ` Russell King - ARM Linux
2010-02-09  0:11 ` [PATCH 13/14] i2c: Add support for the LPC32XX arch wellsk40 at gmail.com
2010-02-09  0:11 ` [PATCH 14/14] WATCHDOG: " wellsk40 at gmail.com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100209165223.GA11113@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).