On 2013-03-15 16:27, H Hartley Sweeten wrote:
On Friday, March 15, 2013 6:40 AM, Ian Abbott wrote:
`labpc_common_detach()` calls `comedi_pci_disable()` unconditionally.
That's okay for PCI devices and harmless for ISA devices (as the
`hw_dev` member will be NULL so `comedi_to_pci_dev()` will return NULL
and `comedi_pci_disable()` checks for that), but it is disastrous for
PCMCIA devices. Those are managed by the "ni_labpc_cs" module but it
calls this `labpc_common_detach()` and the `hw_dev` member will be
pointing to the `struct device` embedded in a `struct pcmcia_device` in
that case. That's enough to confuse `comedi_pci_disable()` into
thinking it's a valid PCI device to be disabled.
Use the private board information (`thisboard`) to make sure it is a PCI
device before calling `comedi_pci_disable()`.
Signed-off-by: Ian Abbott <abbotti@xxxxxxxxx>
---
drivers/staging/comedi/drivers/ni_labpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/ni_labpc.c b/drivers/staging/comedi/drivers/ni_labpc.c
index 78f01709..e032a8c 100644
--- a/drivers/staging/comedi/drivers/ni_labpc.c
+++ b/drivers/staging/comedi/drivers/ni_labpc.c
@@ -805,7 +805,8 @@ void labpc_common_detach(struct comedi_device *dev)
mite_unsetup(devpriv->mite);
mite_free(devpriv->mite);
}
- comedi_pci_disable(dev);
+ if (thisboard->bustype == pci_bustype)
+ comedi_pci_disable(dev);
#endif
};
EXPORT_SYMBOL_GPL(labpc_common_detach);
Hmm.. I overlooked this issue in the ni_labpc driver.
This is fine for now but I think we need to split the bus specific pieces out
and remove all the #ifdef'ery in the ni_labpc module.
This module currently supports ISA and PCI devices and is used with
PCMCIA devices using the ni_labpc_cs module as a wrapper for that
bus support.
We should split it apart like the das08 drivers.
das08.c common code
das08_cs.c PCMCIA bus specific code (auto attach)
das08_isa.c ISA bus specific code (legacy attach)
das08_pci.c PCI bus specific code (auto attach)
In the ni_labpc driver, the ISA dma support can be handled with
callback hooks in the private data.
This will allow removing all the #ifdef'ery as well as the 'bustype'
information from the boardinfo.
After this fix gets in I'll work on splitting it apart.
Thanks. I've started work on splitting amplc_dio200 to get rid of the
ifdef'ery in that driver.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
