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

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

[Grant Likely]

(resend because I forgot to cc the mailing list)

2009/12/9 Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>:
> 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

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev

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

[Uwe Kleine-König]

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-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>:
> > 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.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev

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-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>:
> On Wed, Dec 09, 2009 at 08:08:19AM -0700, Grant Likely wrote:
>> >> 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.

As discussed on IRC, regardless of some of the core & arch use cases.
As far as drivers are concerned, 0 is not a valid IRQ.  Linus'
comments here were referenced: http://lkml.org/lkml/2005/11/21/221

The return of -ENXIO was added in commit 305b3228, and it is
definitely in the workaround category.  Damn.  And a quick grep show a
lot of broken drivers because of it.  (variations on the common 'if
(!irq)' pattern abound as well as a large number of the variant 'if
(irq < 0)').

Well.  Though I don't like it, I will take the patch as testing for <=
0 instead of < 0.  At least that doesn't create new situations of 0
being used as a valid IRQ.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev

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

[Uwe Kleine-König]

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@pengutronix.de>:
> > > 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.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

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@pengutronix.de>:
> 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@pengutronix.de>:
>> > > 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.