Messages in this thread | | | Date | Sat, 15 Jun 2002 16:07:21 -0400 | From | Jeff Garzik <> | Subject | Re: 2.5.20 - Xircom PCI Cardbus doesn't work |
| |
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/
| |