On Wed, Oct 08, 2008 at 11:59:59AM +0200, Geert Uytterhoeven wrote: > On Wed, 8 Oct 2008, Alan Cox wrote: > > On Wed, 08 Oct 2008 09:40:54 +0100 > > David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > > > > On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote: > > > > Zero means no IRQ. Any platform with bits of code left over exposing IRQ > > > > 0 is already not supported by lots of driver code including libata. > > > > > > ...and must implement some kind of interrupt remapping crap just to work > > > around this bogus design decision. > > > > I'll leave you to argue with Linus about that, but since that was the > > decision back in 2005 (for good C reasons) we can safely rely on it. > > `git grep NO_IRQ include arch/*/include' is still quite enlightening... > In the case of PCI where IRQ is unsigned int, that's certainly bogus. The problem originates on platforms where a 1:1 mapping between vector and IRQ exists, where 0 is a valid value. This then needs to be remapped in to an IRQ cookie that has a non-0 value in order to be assigned to dev->irq. Despite whether this is bogus or not, there's not much to be done about it. Those of us with vectored IRQ platforms generally have enough sources that the use of IRQ-0 doesn't matter, and it's not worth the headache of setting up the remapping crap. As an example, on SH, IRQ-0 is mapped to vector 0x200. It is '0' for symbolic reasons only. It's just as easy to pad out irq_desc and treat it as an off-by-1 to work around all of code that assumes NO_IRQ == 0. There is enough code in the kernel today that makes the non-zero IRQ cookie assumption that platforms that do otherwise are simply broken. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
