Re: + spi-imx-correct-check-for-platform_get_irq-failing.patch added to -mm tree

[Grant Likely]

2009/12/9 Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>:
> On Wed, Dec 09, 2009 at 04:32:41PM +0100, Uwe Kleine-König wrote:
>> On Wed, Dec 09, 2009 at 08:08:19AM -0700, Grant Likely wrote:
>> > (resend because I forgot to cc the mailing list)
>> >
>> > 2009/12/9 Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>:
>> > > Hello Grant,
>> > >
>> > > On Tue, Dec 08, 2009 at 05:38:57PM -0700, Grant Likely wrote:
>> > >> > diff -puN drivers/spi/spi_imx.c~spi-imx-correct-check-for-platform_get_irq-failing drivers/spi/spi_imx.c
>> > >> > --- a/drivers/spi/spi_imx.c~spi-imx-correct-check-for-platform_get_irq-failing
>> > >> > +++ a/drivers/spi/spi_imx.c
>> > >> > @@ -554,7 +554,7 @@ static int __init spi_imx_probe(struct p
>> > >> >        }
>> > >> >
>> > >> >        spi_imx->irq = platform_get_irq(pdev, 0);
>> > >> > -       if (!spi_imx->irq) {
>> > >> > +       if (spi_imx->irq < 0) {
>> > >>
>> > >> This changes the old behaviour.  Is that what you intended?  '<= 0' perhaps?
>> > > Yes, the old check was wrong.  What if the irq to use is 0?  I thought
>> > > the commit log to be understandable.  platform_get_irq returns -ENXIO on
>> > > error and an irq number on success.  So 0 has to be interpreted as valid
>> > > irq, not an error.
>> >
>> > 0 is not a valid IRQ
>> Hmm, on my x86 I have:
>>
>>       $ grep '\<0:' /proc/interrupts
>>          0:      24330   IO-APIC-edge      timer
>>
>> arm/davinci starts at 0, too.  As does arm/ns9xxx.  arm/pxa seems to
>> start at 1.  realview starts at 1, too.  So four out of five make are
>> wrong?  Seems like a big area for cleanup.
> I've read a bit and I think the best for a driver writer (i.e. the role
> I have when changing drivers/spi/spi_imx.c) is to accept what
> platform_get_irq returns to me.  If the platform specified
>
>        struct resource mydevicesresources[] = {
>                ...
>                {
>                        .start = 0,
>                        .end = 0,
>                        .flags = IORESOURCE_IRQ,
>                },
>                ...
>        };
>
> then the best thing to do is to take irq0, isn't it.  So as
> platform_get_irq is implemented as
>
>        int platform_get_irq(struct platform_device *dev, unsigned int num)
>        {
>                struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
>
>                return r ? r->start : -ENXIO;
>        }
>
> testing for <0 seems right to me.

Regardless.  I won't accept that change for a theoretical use case.
In the general case I'll maintain the pattern that irq 0 is invalid
unless it is the only way to get around a real problem.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/