[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091216170802.GA26325@pengutronix.de>
Date: Wed, 16 Dec 2009 18:08:03 +0100
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Wolfgang Grandegger <wg@...ndegger.com>
Cc: linux-kernel@...r.kernel.org, David Vrabel <dvrabel@...om.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Urs Thuermann <urs.thuermann@...kswagen.de>,
Oliver Hartkopp <oliver.hartkopp@...kswagen.de>,
"David S. Miller" <davem@...emloft.net>,
Kurt Van Dijck <kurt.van.dijck@....be>,
netdev@...r.kernel.org
Subject: Re: [PATCH 4/7] can/at91: don't check platform_get_irq's return
value against zero
On Wed, Dec 16, 2009 at 05:27:03PM +0100, Wolfgang Grandegger wrote:
> Uwe Kleine-König wrote:
> > platform_get_irq returns -ENXIO on failure, so !irq was probably
> > always true. Better use (int)irq <= 0. Note that a return value of
> > zero is still handled as error even though this could mean irq0.
>
> But only on ARM, which is the only platform still using the infamous
> NO_IRQ (=-1). As this is a driver for ARM hardware, using irq == NO_IRQ
> would make sense, though.
This has nothing to do with NO_IRQ. You could do:
- if (!res || !irq) {
+ if (!res || irq <= (int)NO_IRQ) {
but this looks too ugly. (IMHO using NO_IRQ is already ugly.)
Still, before my patch platform_get_irq return 0 was an error and if
this should be handled as irq0 this is a separate issue that should be
fixed in a separate patch.
Best regards
Uwe
PS:
linux-2.6$ git grep -E 'define *NO_IRQ\>' arch/*/include
arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))
arch/microblaze/include/asm/irq.h:#define NO_IRQ (-1)
arch/mn10300/include/asm/irq.h:#define NO_IRQ INT_MAX
arch/parisc/include/asm/irq.h:#define NO_IRQ (-1)
arch/powerpc/include/asm/irq.h:#define NO_IRQ (0)
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists