On Wednesday, January 30, 2013 5:01 AM, Ian Abbott wrote: > On 2013-01-29 23:18, H Hartley Sweeten wrote: >> Separate the comedi_pci_* functions out of drivers.c into a new >> source file, comedi_pci.c. This allows conditionally building >> support for comedi PCI drivers into the comedi core. Fix the >> Kconfig and Makefile appropriately. >> >> Group all the comedi_pci_* prototypes and related defines into one >> place in comedidev.h. Protect these prototypes with an #ifdef so >> that building a comedi pci driver without PCI support will cause a >> build error. This will normally not happen as long as the comedi >> PCI driver is placed in the proper group in the Kconfig. > > I'm pretty certain this will cause compilation warnings for some mixed > ISA/PCI drivers unless dummy replacements for comedi_pci_enable() and > comedi_pci_disable() are provided. For example, disabling > CONFIG_COMEDI_PCI, but enabling CONFIG_COMEDI_AMPLC_DIO200 will get > result in some compiler warning in dio200_auto_attach(). If > CONFIG_COMEDI_PCI is disabled, this never actually gets called (since > the PCI driver never gets registered), but is linked to from > amplc_dio200_driver.auto_attach. In this case, it compiles down to a > dummy function returning -EINVAL, and the part of the function that > calls comedi_pci_enable() will be optimized out, but the compiler will > still issue a warning about the call to comedi_pci_enable() with no > prototype. Similarly, the call to comedi_pci_disable() in > dio200_detach() is optimized out but the compiler will still complain. > > If it *is* just a warning, the dummy inline versions of > comedi_pci_enable() and comedi_pci_disable() can be added in a separate > patch. Ah.. I overlooked the dual isa/pci drivers. You are correct, for those to compile cleanly we will need a couple dummy (return -EINVAL or maybe -ENOSYS) functions. It might be cleaner to split those drivers into a core (isa) driver and a pci wrapper driver. Similar to how the das08 and das08_cs driver is split. This would also get rid of the #ifdef'ery in the drivers. > I'd give it a quick test, but I'm currently struggling to get your first > patch (and probably some of the later ones) to apply to (a clone of) > Greg's staging-next branch for some reason! Hmm. I still need to pull Greg's staging-next branch. The series was based on top of next-20130128. Greg's branch might have some patches in it that have not hit next yet. I'll try to resolve it today and repost the series. Can you give the series a quick review and let me know if there is anything I need to address? Thanks, Hartley _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
