Linus Torvalds wrote:
> which is horribly stupid. We really want to do
>
> pci_enable_mem(dev);
> membase = ioremap(dev->resource[]);
>
> pci_request_irq(dev, irq_handler);
>
> where "pci_request_irq()" enables the interrupt and adds an interrupt
> handler atomically.
That seems ok to me. Note that we still want
pci_{enable,disable}_device to exist (as mentioned in the mail to
Kai)... I'm fine with moving a lot of pci_enable_device's duties to
pci_{assign,request,release}_{irq,io,mem} as long as we don't kill it
completely.
>>The only thing I've wanted is a cross-platform way to detect if
>>pdev->irq returned by pci_enable_device is valid.
>
>
> It's required to be valid, because if it isn't, then the platform is
> broken. There are no cross-platform issues: complain to the platform
> vendor and/or the linux code for that architecture.
Well, then I should either complain to myself, or to you ;-) Part of
this comes back to PCI irq routing. The actual situation encountered is,
When ia32 PCI irq routing messes up, or some other random reason why an
irq is not available for a PCI device, pdev->irq==0. So I test for that
in my code. Then DaveM bitches at me for my test (pdev->irq < 2) not
being cross-platform.
My suggested solution, if you like Kai's proposal, is to have
pci_assign_irq() or pci_request_irq() return an error if PCI IRQ routing
fails.
Jeff
P.S. Random tangent: the PCI layer could do a lot better job at
spreading devices across the available IRQs. I've seen devices
clustered on a single interrupt by the Linux PCI code, where their pci
irq routing masks indicating other, not-assigned-at-all irqs were available.
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:33 EST