Messages in this thread | | | Date | Mon, 21 Nov 2005 12:43:48 -0700 | From | Matthew Wilcox <> | Subject | Re: [PATCH 4/5] Centralise NO_IRQ definition |
| |
On Mon, Nov 21, 2005 at 11:27:05AM -0800, Linus Torvalds wrote: > On Mon, 21 Nov 2005, Matthew Wilcox wrote: > > > > On Mon, Nov 21, 2005 at 10:55:24AM -0800, Linus Torvalds wrote: > > > Quite frankly, if we change [PCI_]NO_IRQ to -1, there's almost certainly > > > going to be a lot of drivers breaking. > > > > There's only one driver using NO_IRQ today (outside of architectures > > which define NO_IRQ to -1, that is). So *this* series of patches should > > break nothing. > > Right. But the point is that most drivers will do something like > > if (!dev->irq) > return; > > (whatever, made up). And that having NO_IRQ be anything but 0 is thus > fundamentally broken.
The idea was to give them something better to use instead of this. Whether that be if (has_irq(dev)) return; or some other similar construct, I'm not terribly fussed.
> I'm NOT talking about PCI specs. > > I'm talking about real hardware. > > Read pretty much _any_ data-sheet for an interrupt router, and you'll see > that the bit pattern 0000 means _disabled_.
The only relevant thing I found with google was http://www.microsoft.com/whdc/archive/pciirq.mspx
Where it talks about 0 meaning disabled, it says:
Link Value for INTn#:A value of zero means this interrupt pin is not connected to any other interrupt pins and is not connected to any of the Interrupt Router's interrupt pins.
which is a different bit from where it talks about the AT-compatible IRQ numbers.
Everything else I find seems to be talking about Arcnet hardware (!) - 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/
| |