Messages in this thread | | | From | Grant Likely <> | Date | Wed, 9 Dec 2009 11:00:19 -0700 | Subject | Re: + spi-imx-correct-check-for-platform_get_irq-failing.patch added to -mm tree |
| |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |