On Sat, 15 Jun 2002, Linus Torvalds wrote:
> On Sat, 15 Jun 2002, Linus Torvalds wrote:
> >
> > Right now the solution to a screaming device can be something as nasty as
> >
> > cli();
> > pci_enable_device();
> > disable_irq(dev->irq);
> > sti();
> >
> > /* IRQ handling needs this ioremapped */
> > membase = ioremap(dev->resource[]);
> > request_irq(dev->irq);
> >
> > /* Now we can enable the irq, because we have a valid handler */
> > enable_irq(dev->irq);
>
> Side note: the other approach to screaming devices is to pray that they
> don't happen.
I think there are situations where we don't have a choice but praying
anyway. Since there's no PCI_COMMAND_IRQ, the only way to suppress IRQs
AFAICS is to not route them (well, or ignore them, which is what we do if
there's no handler installed), but that's just not possible when the IRQ
line is shared with some other active device.
I still think it's probably a good idea to replace pci_enable_device()
by a more fine-grained API, which allows a driver author to specify
which exact resources he needs.
In the normal case, a driver would only use a subset of the following
three functions as needed:
int pci_request_irq(pci_dev, handler, ...);
unsigned long pci_request_io(pci_dev, nr);
unsigned long pci_request_mmio(pci_dev, nr);
(plus appropriate s/request/release/ of course)
Internally, they'd do the right thing, i.e. assign and enable resources as
needed.
At least for the _irq case an associated
int pci_assign_irq(pci_dev);
is useful, since some drivers (e.g. net, serial) only request their irq
when the device is opened (which make sense for performance reasons with
shared irqs), but it'd still be nice to fail the ::probe() when no IRQ can
be assigned.
So a complete API would be
pci_request_{irq,io,mmio}
pci_release_{irq,io,mmio}
pci_enable_{irq,io,mmio}
pci_assign_{irq,io,mmio}
but normally a driver would just use pci_request/release_*() + maybe
pci_assign_irq(), which will take care of the appropriate assign/enable
internally.
--Kai
-
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