`comedi_device_detach()` does nothing if the `struct comedi_device`'s
`attached` member is false, otherwise it calls
`__comedi_device_detach()` to do the real work.
`__comedi_device_detach()` is called from various other functions in
"drivers.c" (`comedi_device_postconfig()`, `comedi_device_attach()`, and
`comedi_auto_config()`) to bypass the check for the `attached` member
being false.
If we make `__comedi_device_detach()` safe to call when the `attached`
member is already false, we can remove the check in
`comedi_device_detach()`, subsume `__comedi_device_detach()` within
`comedi_device_detach()`, and replace all the calls to
`__comedi_device_detach()` with calls to `comedi_device_detach()`.
In fact, it is already safe to call `__comedi_device_detach()` when the
`attached` member is false. We just need to remove the warning message
it outputs when the `driver` member is NULL. Then the function becomes
idempotent without outputting spurious warnings. (It is idempotent
because `dev->driver->detach()` will only be called once at most and the
call to `cleanup_device()` is idempotent itself.)
Combine `comedi_device_detach()` with `__comedi_device_detach()`,
removing the check for the `attached` member being false and removing
the warning about the `driver` member being NULL, and replace all calls
to `__comedi_device_detach()` with calls to the combined
`comedi_device_detach()`.
A beneficial side-effect of the above change is that a call to
`comedi_device_detach()` will always result in a call to
`cleanup_device()` and so always result in a call to
`comedi_clear_hw_dev()`. We will make use of this beneficial
side-effect in a later patch.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>