Messages in this thread | | | Date | Mon, 21 Nov 2005 10:55:24 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH 4/5] Centralise NO_IRQ definition |
| |
On Mon, 21 Nov 2005, Matthew Wilcox wrote: > > On Mon, Nov 21, 2005 at 11:12:36AM +0000, David Howells wrote: > > Matthew Wilcox <matthew@wil.cx> wrote: > > > > > +#define NO_IRQ ((unsigned int)(-1)) > > > > Should this be wrapped with #ifndef? > > *sigh*. The one piece of feedback I got on the last series was from > Ingo, and he asked that I *not* wrap it with ifndef. So, no.
Quite frankly, if we change [PCI_]NO_IRQ to -1, there's almost certainly going to be a lot of drivers breaking.
On x86, 0 has been the lack of IRQ since basically forever, in one form or another (for devices, that is - there _is_ a timer irq 0, but that's set up separately).
Which means that I'd _much_ prefer to other architectures to just follow suit.
So for an architecture where irq0 is a valid physical interrupt for a device, why not just translate that "real irq 0" into some other thing? Much less likely to break anything.
In fact, it could be as simple as setting the high bit for any valid interrupt, and then just masking it out in request_irq() and friends. Do something like
#define PCI_IRQ_VALID_MASK (1u << 31)
and then if the physical irq is 0, just or in that VALID mask, turning the interrupt into a non-zero, and then when registering it, just and it away again..
This is not theory: a _lot_ of real-life PCI devices very much think that irq 0 means "disabled". Not even just in drivers - in actual _hardware_. When you write 0 to the irq number for irq routers, they disable that line. So the "zero as NO_IRQ" is more than just a "several drivers think that is how it is", it's how a lot of hardware actually works.
Linus
- 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/
| |