`comedi_auto_config()` is usually called from the probe routine of a
low-level comedi driver to allocate and auto-configure a comedi device.
Part of this involves calling the low-level driver's `auto_attach()`
handler, and if that is successful, `comedi_device_postconfig()` tries
to complete the configuration of the comedi device. If either of those
fail, `comedi_device_detach()` is called to clean up, and
`comedi_release_hardware_device()` is called to remove the dynamically
allocated comedi device.
Unfortunately, `comedi_device_detach()` clears the `hw_dev` member of
the `struct comedi_device` (indirectly via `comedi_clear_hw_dev()`), and
that stops `comedi_release_hardware_device()` finding the comedi device
associated with the hardware device, so the comedi device won't be
removed properly.
Since `comedi_release_hardware_device()` also calls
`comedi_device_detach()` (assuming it finds the comedi device associated
with the hardware device), the fix is to remove the direct call to
`comedi_device_detach()` from `comedi_auto_config()` and let the call to
`comedi_release_hardware_device()` take care of it.
Signed-off-by: Ian Abbott <abbotti@xxxxxxxxx>
---
drivers/staging/comedi/drivers.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
index 2460803..5b15033 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -616,8 +616,6 @@ int comedi_auto_config(struct device *hardware_device,
ret = driver->auto_attach(dev, context);
if (ret >= 0)
ret = comedi_device_postconfig(dev);
- if (ret < 0)
- comedi_device_detach(dev);
mutex_unlock(&dev->mutex);
if (ret < 0) {
--
1.8.5.3
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
