[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B292DA9.8040009@grandegger.com>
Date: Wed, 16 Dec 2009 19:57:45 +0100
From: Wolfgang Grandegger <wg@...ndegger.com>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
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
Uwe Kleine-König wrote:
> 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:
Right, sorry for the noise.
> - 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.
"irq <= 0" seems then the best solution. Will add my signed-off-by to
the patch.
Thanks,
Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists