On Monday 26 March 2007 21:29, Eric W. Biederman wrote: > "Luck, Tony" <[EMAIL PROTECTED]> writes: > > >> What I'm proposing we do is move the irq allocation code out of > >> pci_enable_device and the irq freeing code out of pci_disable_device > >> in the future. > > > > Sounds rational ... in a world that wasn't dominated by PCI it would > > seem to be the logical approach (since the irq code would have much > > more utility independent of the PCI code). > > Right. We can even do this earlier in the pci code. Just doing this > on demand when the device driver needs it is problematic. As devices > drivers like to keep the requested over a pci_disable_device pci_enable_device > pair. > > The big practical issue is that we will like wind up allocating an irq > number to all usable irqs on ia64. Which means we will like need many > more irq numbers... Although I guess if we keep it at the pci layer > we should be fairly safe.
The main reason we wait until pci_enable_device() to allocate an IRQ number is that ia64 currently only has about 180 device vectors, and there are machines with more PCI slots than that. I also think it's nice that we don't do anything with a device until we have a driver to claim it. But there certainly have been cases where delaying IRQ allocation has caused troubles. I really like the idea of moving to the IRQ == GSI model for ia64. But of course, we'll have to get rid of the 180-vector limit to make that work, too. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
