Hi Jeff,
> Would you mind reviewing pci.h to make sure that all necessary functions
> are exported when CONFIG_PCI is not defined?
>
> I think that some of the recent PCI additions were not available for the
> !CONFIG_PCI case. This is wrong IMHO because pci.h is specifically
> designed to provide support to drivers even when CONFIG_PCI is
> undefined. It leads to much cleaner driver code.
I'm not sure at all that this is the right way to go.
With the old PCI interface, you could use
struct pci_dev *dev = NULL;
while (dev = pci_find_dev(VENDOR, DEVICE, dev)) {
pci_enable_device(dev);
init_your_device(dev->resource[0].start);
}
and it magically went optimized away by the compiler if CONFIG_PCI wasn't
defined. With the new interface, it would look this way:
int my_probe(struct pci_dev *dev)
{
pci_enable_device(dev);
init_your_device(dev->resource[0].start);
return 0;
}
struct pci_device_id my_ids[] = { ... };
struct pci_driver my_driver {
...
id_table: my_ids,
probe: my_probe,
}
{ pci_register_driver(&my_driver);
in which case nothing gets optimized away when compiling without CONFIG_PCI
and you end up with the driver full of dead code. Therefore to be on the
clean side of the glass, you need #ifdef CONFIG_PCI anyway, so there isn't
much sense in providing pci_register_driver() stub for PCI-less cases.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Anything is good and useful if it's made of chocolate."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:11 EST