2009/12/9 Uwe Kleine-König <[email protected]>: > 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 _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
