linux/drivers/comedi/drivers.c

1183 lines
34 KiB

staging: comedi: replace __comedi_device_detach() `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>
2013-04-04 14:58:58 +01:00
staging: comedi: introduce comedi_timeout() Introduce a comedi core helper function to handle the boilerplate needed by the drivers to busy- wait for a condition to occur. Typically this condition is the analog input/output end-of-conversion used with the comedi (*insn_read) and (*insn_write) operations. To use this function, the drivers just need to provide a callback that checks for the desired condition. The callback should return 0 if the condition is met or -EBUSY if it is still waiting. Any other errno will be returned to the caller. If the timeout occurs before the condition is met -ETIMEDOUT will be returned. The parameters to the callback function are the comedi_device, comedi_subdevice, and comedi_insn pointers that were passed to the (*insn_read) or (*insn_write) as well as an unsigned long, driver specific, 'context' that can be used to pass any other information that might be needed in the callback. This 'context' could be anything such as the register offset to read the status or the bits needed to check the status. The comedi_timeout() function itself does not use any of these parameters. This will help remove all the crazy "wait this many loops" used by some of the drivers. It also creates a common errno for comedi to detect when a timeout occurs. ADC/DAC conversion times are typically pretty fast, usually around 100K samples/sec (10 usec). A conservative timeout of 1 second is used in comedi_timeout(). Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-10 11:49:00 -07:00
staging: comedi: introduce comedi_timeout() Introduce a comedi core helper function to handle the boilerplate needed by the drivers to busy- wait for a condition to occur. Typically this condition is the analog input/output end-of-conversion used with the comedi (*insn_read) and (*insn_write) operations. To use this function, the drivers just need to provide a callback that checks for the desired condition. The callback should return 0 if the condition is met or -EBUSY if it is still waiting. Any other errno will be returned to the caller. If the timeout occurs before the condition is met -ETIMEDOUT will be returned. The parameters to the callback function are the comedi_device, comedi_subdevice, and comedi_insn pointers that were passed to the (*insn_read) or (*insn_write) as well as an unsigned long, driver specific, 'context' that can be used to pass any other information that might be needed in the callback. This 'context' could be anything such as the register offset to read the status or the bits needed to check the status. The comedi_timeout() function itself does not use any of these parameters. This will help remove all the crazy "wait this many loops" used by some of the drivers. It also creates a common errno for comedi to detect when a timeout occurs. ADC/DAC conversion times are typically pretty fast, usually around 100K samples/sec (10 usec). A conservative timeout of 1 second is used in comedi_timeout(). Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-10 11:49:00 -07:00
staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest `ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO subdevice (subdevice 2) of supported National Instruments M-series cards. It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST` ioctls for this subdevice. There are two causes for a possible divide-by-zero error when validating that the `stop_arg` member of the passed-in command is not too large. The first cause for the divide-by-zero is that calls to `comedi_bytes_per_scan()` are only valid once the command has been copied to `s->async->cmd`, but that copy is only done for the `COMEDI_CMD` ioctl. For the `COMEDI_CMDTEST` ioctl, it will use whatever was left there by the previous `COMEDI_CMD` ioctl, if any. (This is very likely, as it is usual for the application to use `COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous, valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()` will return 0, so the subsequent division in `ni_cdio_cmdtest()` of `s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a divide-by-zero error. To fix this error, call a new function `comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing `comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for its calculations. (Also refactor `comedi_bytes_per_scan()` to call the new function.) Once the first cause for the divide-by-zero has been fixed, the second cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0. Fix it by only performing the division (and validating that `stop_arg` is no more than the maximum value) if `comedi_bytes_per_scan_cmd()` returns a non-zero value. The problem was reported on the COMEDI mailing list here: https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM Reported-by: Ivan Vasilyev <grabesstimme@gmail.com> Tested-by: Ivan Vasilyev <grabesstimme@gmail.com> Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio output") Cc: <stable@vger.kernel.org> # 4.6+ Cc: Spencer E. Olson <olsonse@umich.edu> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-04 14:33:54 +00:00
staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest `ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO subdevice (subdevice 2) of supported National Instruments M-series cards. It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST` ioctls for this subdevice. There are two causes for a possible divide-by-zero error when validating that the `stop_arg` member of the passed-in command is not too large. The first cause for the divide-by-zero is that calls to `comedi_bytes_per_scan()` are only valid once the command has been copied to `s->async->cmd`, but that copy is only done for the `COMEDI_CMD` ioctl. For the `COMEDI_CMDTEST` ioctl, it will use whatever was left there by the previous `COMEDI_CMD` ioctl, if any. (This is very likely, as it is usual for the application to use `COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous, valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()` will return 0, so the subsequent division in `ni_cdio_cmdtest()` of `s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a divide-by-zero error. To fix this error, call a new function `comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing `comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for its calculations. (Also refactor `comedi_bytes_per_scan()` to call the new function.) Once the first cause for the divide-by-zero has been fixed, the second cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0. Fix it by only performing the division (and validating that `stop_arg` is no more than the maximum value) if `comedi_bytes_per_scan_cmd()` returns a non-zero value. The problem was reported on the COMEDI mailing list here: https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM Reported-by: Ivan Vasilyev <grabesstimme@gmail.com> Tested-by: Ivan Vasilyev <grabesstimme@gmail.com> Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio output") Cc: <stable@vger.kernel.org> # 4.6+ Cc: Spencer E. Olson <olsonse@umich.edu> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-04 14:33:54 +00:00
staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest `ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO subdevice (subdevice 2) of supported National Instruments M-series cards. It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST` ioctls for this subdevice. There are two causes for a possible divide-by-zero error when validating that the `stop_arg` member of the passed-in command is not too large. The first cause for the divide-by-zero is that calls to `comedi_bytes_per_scan()` are only valid once the command has been copied to `s->async->cmd`, but that copy is only done for the `COMEDI_CMD` ioctl. For the `COMEDI_CMDTEST` ioctl, it will use whatever was left there by the previous `COMEDI_CMD` ioctl, if any. (This is very likely, as it is usual for the application to use `COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous, valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()` will return 0, so the subsequent division in `ni_cdio_cmdtest()` of `s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a divide-by-zero error. To fix this error, call a new function `comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing `comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for its calculations. (Also refactor `comedi_bytes_per_scan()` to call the new function.) Once the first cause for the divide-by-zero has been fixed, the second cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0. Fix it by only performing the division (and validating that `stop_arg` is no more than the maximum value) if `comedi_bytes_per_scan_cmd()` returns a non-zero value. The problem was reported on the COMEDI mailing list here: https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM Reported-by: Ivan Vasilyev <grabesstimme@gmail.com> Tested-by: Ivan Vasilyev <grabesstimme@gmail.com> Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio output") Cc: <stable@vger.kernel.org> # 4.6+ Cc: Spencer E. Olson <olsonse@umich.edu> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-04 14:33:54 +00:00
staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest `ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO subdevice (subdevice 2) of supported National Instruments M-series cards. It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST` ioctls for this subdevice. There are two causes for a possible divide-by-zero error when validating that the `stop_arg` member of the passed-in command is not too large. The first cause for the divide-by-zero is that calls to `comedi_bytes_per_scan()` are only valid once the command has been copied to `s->async->cmd`, but that copy is only done for the `COMEDI_CMD` ioctl. For the `COMEDI_CMDTEST` ioctl, it will use whatever was left there by the previous `COMEDI_CMD` ioctl, if any. (This is very likely, as it is usual for the application to use `COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous, valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()` will return 0, so the subsequent division in `ni_cdio_cmdtest()` of `s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a divide-by-zero error. To fix this error, call a new function `comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing `comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for its calculations. (Also refactor `comedi_bytes_per_scan()` to call the new function.) Once the first cause for the divide-by-zero has been fixed, the second cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0. Fix it by only performing the division (and validating that `stop_arg` is no more than the maximum value) if `comedi_bytes_per_scan_cmd()` returns a non-zero value. The problem was reported on the COMEDI mailing list here: https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM Reported-by: Ivan Vasilyev <grabesstimme@gmail.com> Tested-by: Ivan Vasilyev <grabesstimme@gmail.com> Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio output") Cc: <stable@vger.kernel.org> # 4.6+ Cc: Spencer E. Olson <olsonse@umich.edu> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-04 14:33:54 +00:00
staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest `ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO subdevice (subdevice 2) of supported National Instruments M-series cards. It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST` ioctls for this subdevice. There are two causes for a possible divide-by-zero error when validating that the `stop_arg` member of the passed-in command is not too large. The first cause for the divide-by-zero is that calls to `comedi_bytes_per_scan()` are only valid once the command has been copied to `s->async->cmd`, but that copy is only done for the `COMEDI_CMD` ioctl. For the `COMEDI_CMDTEST` ioctl, it will use whatever was left there by the previous `COMEDI_CMD` ioctl, if any. (This is very likely, as it is usual for the application to use `COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous, valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()` will return 0, so the subsequent division in `ni_cdio_cmdtest()` of `s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a divide-by-zero error. To fix this error, call a new function `comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing `comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for its calculations. (Also refactor `comedi_bytes_per_scan()` to call the new function.) Once the first cause for the divide-by-zero has been fixed, the second cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0. Fix it by only performing the division (and validating that `stop_arg` is no more than the maximum value) if `comedi_bytes_per_scan_cmd()` returns a non-zero value. The problem was reported on the COMEDI mailing list here: https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM Reported-by: Ivan Vasilyev <grabesstimme@gmail.com> Tested-by: Ivan Vasilyev <grabesstimme@gmail.com> Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio output") Cc: <stable@vger.kernel.org> # 4.6+ Cc: Spencer E. Olson <olsonse@umich.edu> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-04 14:33:54 +00:00
2015-10-23 10:56:09 +01:00
2015-10-23 10:56:09 +01:00
staging: comedi: simplify driver module counting For a legacy device attachment with the `COMEDI_DEVCONFIG` ioctl, `do_devconfig_ioctl()` calls `comedi_device_attach()` to find a matching device driver and attach the device. It then tries to increment the device driver's module count and if that fails it detaches the device. So on successful attachment of a device by the `COMEDI_DEVCONFIG` ioctl, the device driver's module count will have been incremented. `comedi_device_attach()` is called from nowhere else. It already increments the device driver's module count temporarily and decrements it again; if it gets as far as calling `comedi_device_postconfig()` the module count is decremented within that function. Simplify the above by removing the decrement of the device driver module count from `comedi_device_postconfig()`. If the call to `comedi_device_postconfig()` succeeds, `comedi_device_attach()` will return with the module count still incremented, otherwise decrement the module count before returning the error. Don't try and increment the module count in `do_devconfig_ioctl()` after a successful return from `comedi_device_attach()` as the module count has now already been incremented. `comedi_device_postconfig()` is also called by `comedi_auto_config()` which currently has to increment the device driver's module count temporarily so that `comedi_device_postconfig()` can decrement it, but always returns with no overall change to the module count. Remove all the module count manipulations from `comedi_device_postconfig()`. There is no other reason for `comedi_auto_config()` to increment the device driver's module count temporarily, since it is only called (indirectly) from the device driver itself (usually via one of the wrappers `comedi_pci_auto_config()` or `comedi_usb_auto_config()`). 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>
2013-04-04 14:58:56 +01:00
staging: comedi: simplify driver module counting For a legacy device attachment with the `COMEDI_DEVCONFIG` ioctl, `do_devconfig_ioctl()` calls `comedi_device_attach()` to find a matching device driver and attach the device. It then tries to increment the device driver's module count and if that fails it detaches the device. So on successful attachment of a device by the `COMEDI_DEVCONFIG` ioctl, the device driver's module count will have been incremented. `comedi_device_attach()` is called from nowhere else. It already increments the device driver's module count temporarily and decrements it again; if it gets as far as calling `comedi_device_postconfig()` the module count is decremented within that function. Simplify the above by removing the decrement of the device driver module count from `comedi_device_postconfig()`. If the call to `comedi_device_postconfig()` succeeds, `comedi_device_attach()` will return with the module count still incremented, otherwise decrement the module count before returning the error. Don't try and increment the module count in `do_devconfig_ioctl()` after a successful return from `comedi_device_attach()` as the module count has now already been incremented. `comedi_device_postconfig()` is also called by `comedi_auto_config()` which currently has to increment the device driver's module count temporarily so that `comedi_device_postconfig()` can decrement it, but always returns with no overall change to the module count. Remove all the module count manipulations from `comedi_device_postconfig()`. There is no other reason for `comedi_auto_config()` to increment the device driver's module count temporarily, since it is only called (indirectly) from the device driver itself (usually via one of the wrappers `comedi_pci_auto_config()` or `comedi_usb_auto_config()`). 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>
2013-04-04 14:58:56 +01:00
staging: comedi: replace __comedi_device_detach() `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>
2013-04-04 14:58:58 +01:00
staging: comedi: simplify driver module counting For a legacy device attachment with the `COMEDI_DEVCONFIG` ioctl, `do_devconfig_ioctl()` calls `comedi_device_attach()` to find a matching device driver and attach the device. It then tries to increment the device driver's module count and if that fails it detaches the device. So on successful attachment of a device by the `COMEDI_DEVCONFIG` ioctl, the device driver's module count will have been incremented. `comedi_device_attach()` is called from nowhere else. It already increments the device driver's module count temporarily and decrements it again; if it gets as far as calling `comedi_device_postconfig()` the module count is decremented within that function. Simplify the above by removing the decrement of the device driver module count from `comedi_device_postconfig()`. If the call to `comedi_device_postconfig()` succeeds, `comedi_device_attach()` will return with the module count still incremented, otherwise decrement the module count before returning the error. Don't try and increment the module count in `do_devconfig_ioctl()` after a successful return from `comedi_device_attach()` as the module count has now already been incremented. `comedi_device_postconfig()` is also called by `comedi_auto_config()` which currently has to increment the device driver's module count temporarily so that `comedi_device_postconfig()` can decrement it, but always returns with no overall change to the module count. Remove all the module count manipulations from `comedi_device_postconfig()`. There is no other reason for `comedi_auto_config()` to increment the device driver's module count temporarily, since it is only called (indirectly) from the device driver itself (usually via one of the wrappers `comedi_pci_auto_config()` or `comedi_usb_auto_config()`). 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>
2013-04-04 14:58:56 +01:00
staging: comedi: simplify driver module counting For a legacy device attachment with the `COMEDI_DEVCONFIG` ioctl, `do_devconfig_ioctl()` calls `comedi_device_attach()` to find a matching device driver and attach the device. It then tries to increment the device driver's module count and if that fails it detaches the device. So on successful attachment of a device by the `COMEDI_DEVCONFIG` ioctl, the device driver's module count will have been incremented. `comedi_device_attach()` is called from nowhere else. It already increments the device driver's module count temporarily and decrements it again; if it gets as far as calling `comedi_device_postconfig()` the module count is decremented within that function. Simplify the above by removing the decrement of the device driver module count from `comedi_device_postconfig()`. If the call to `comedi_device_postconfig()` succeeds, `comedi_device_attach()` will return with the module count still incremented, otherwise decrement the module count before returning the error. Don't try and increment the module count in `do_devconfig_ioctl()` after a successful return from `comedi_device_attach()` as the module count has now already been incremented. `comedi_device_postconfig()` is also called by `comedi_auto_config()` which currently has to increment the device driver's module count temporarily so that `comedi_device_postconfig()` can decrement it, but always returns with no overall change to the module count. Remove all the module count manipulations from `comedi_device_postconfig()`. There is no other reason for `comedi_auto_config()` to increment the device driver's module count temporarily, since it is only called (indirectly) from the device driver itself (usually via one of the wrappers `comedi_pci_auto_config()` or `comedi_usb_auto_config()`). 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>
2013-04-04 14:58:56 +01:00
staging: comedi: add bus-type-specific attach hooks for PCI and USB The Comedi auto-configuration mechanism used to bind hardware devices to comedi devices automatically is pretty kludgy. It fakes a "manual" configuration of the comedi device as though the COMEDI_DEVCONFIG ioctl (or the 'comedi_config' utility) were used. In particular, the low-level comedi driver's '->attach()' routine is called with a pointer to the struct comedi_device being attached and a pointer to a 'struct devconfig' containing a device name string and a few integer options to help the attach routine locate the device being attached. In the case of PCI devices, these integer options are the PCI bus and slot numbers. In the case of USB devices, there are no integer options and it relies more on pot luck to attach the correct device. This patch adds a couple of bus-type-specific attach routine hooks to the struct comedi_driver, which a low-level driver can optionally fill in if it supports auto-configuration. A low-level driver that supports auto-configuration of {PCI,USB} devices calls the existing comedi_{pci,usb}_auto_config() when it wishes to auto-configure a freshly probed device (maybe after loading firmware). This will call the new '->attach_{pci,usb}()' hook if the driver has defined it, otherwise it will fall back to calling the '->attach()' hook as before. The '->attach_{pci,usb}()' hook gets a pointer to the struct comedi_device and a pointer to the struct {pci_dev,usb_interface} and can figure out the {PCI,USB} device details for itself. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-30 17:15:01 +01:00
staging: comedi: add bus-type-specific attach hooks for PCI and USB The Comedi auto-configuration mechanism used to bind hardware devices to comedi devices automatically is pretty kludgy. It fakes a "manual" configuration of the comedi device as though the COMEDI_DEVCONFIG ioctl (or the 'comedi_config' utility) were used. In particular, the low-level comedi driver's '->attach()' routine is called with a pointer to the struct comedi_device being attached and a pointer to a 'struct devconfig' containing a device name string and a few integer options to help the attach routine locate the device being attached. In the case of PCI devices, these integer options are the PCI bus and slot numbers. In the case of USB devices, there are no integer options and it relies more on pot luck to attach the correct device. This patch adds a couple of bus-type-specific attach routine hooks to the struct comedi_driver, which a low-level driver can optionally fill in if it supports auto-configuration. A low-level driver that supports auto-configuration of {PCI,USB} devices calls the existing comedi_{pci,usb}_auto_config() when it wishes to auto-configure a freshly probed device (maybe after loading firmware). This will call the new '->attach_{pci,usb}()' hook if the driver has defined it, otherwise it will fall back to calling the '->attach()' hook as before. The '->attach_{pci,usb}()' hook gets a pointer to the struct comedi_device and a pointer to the struct {pci_dev,usb_interface} and can figure out the {PCI,USB} device details for itself. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-30 17:15:01 +01:00
staging: comedi: add bus-type-specific attach hooks for PCI and USB The Comedi auto-configuration mechanism used to bind hardware devices to comedi devices automatically is pretty kludgy. It fakes a "manual" configuration of the comedi device as though the COMEDI_DEVCONFIG ioctl (or the 'comedi_config' utility) were used. In particular, the low-level comedi driver's '->attach()' routine is called with a pointer to the struct comedi_device being attached and a pointer to a 'struct devconfig' containing a device name string and a few integer options to help the attach routine locate the device being attached. In the case of PCI devices, these integer options are the PCI bus and slot numbers. In the case of USB devices, there are no integer options and it relies more on pot luck to attach the correct device. This patch adds a couple of bus-type-specific attach routine hooks to the struct comedi_driver, which a low-level driver can optionally fill in if it supports auto-configuration. A low-level driver that supports auto-configuration of {PCI,USB} devices calls the existing comedi_{pci,usb}_auto_config() when it wishes to auto-configure a freshly probed device (maybe after loading firmware). This will call the new '->attach_{pci,usb}()' hook if the driver has defined it, otherwise it will fall back to calling the '->attach()' hook as before. The '->attach_{pci,usb}()' hook gets a pointer to the struct comedi_device and a pointer to the struct {pci_dev,usb_interface} and can figure out the {PCI,USB} device details for itself. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-30 17:15:01 +01:00
staging: comedi: add bus-type-specific attach hooks for PCI and USB The Comedi auto-configuration mechanism used to bind hardware devices to comedi devices automatically is pretty kludgy. It fakes a "manual" configuration of the comedi device as though the COMEDI_DEVCONFIG ioctl (or the 'comedi_config' utility) were used. In particular, the low-level comedi driver's '->attach()' routine is called with a pointer to the struct comedi_device being attached and a pointer to a 'struct devconfig' containing a device name string and a few integer options to help the attach routine locate the device being attached. In the case of PCI devices, these integer options are the PCI bus and slot numbers. In the case of USB devices, there are no integer options and it relies more on pot luck to attach the correct device. This patch adds a couple of bus-type-specific attach routine hooks to the struct comedi_driver, which a low-level driver can optionally fill in if it supports auto-configuration. A low-level driver that supports auto-configuration of {PCI,USB} devices calls the existing comedi_{pci,usb}_auto_config() when it wishes to auto-configure a freshly probed device (maybe after loading firmware). This will call the new '->attach_{pci,usb}()' hook if the driver has defined it, otherwise it will fall back to calling the '->attach()' hook as before. The '->attach_{pci,usb}()' hook gets a pointer to the struct comedi_device and a pointer to the struct {pci_dev,usb_interface} and can figure out the {PCI,USB} device details for itself. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-30 17:15:01 +01:00
staging: comedi: add bus-type-specific attach hooks for PCI and USB The Comedi auto-configuration mechanism used to bind hardware devices to comedi devices automatically is pretty kludgy. It fakes a "manual" configuration of the comedi device as though the COMEDI_DEVCONFIG ioctl (or the 'comedi_config' utility) were used. In particular, the low-level comedi driver's '->attach()' routine is called with a pointer to the struct comedi_device being attached and a pointer to a 'struct devconfig' containing a device name string and a few integer options to help the attach routine locate the device being attached. In the case of PCI devices, these integer options are the PCI bus and slot numbers. In the case of USB devices, there are no integer options and it relies more on pot luck to attach the correct device. This patch adds a couple of bus-type-specific attach routine hooks to the struct comedi_driver, which a low-level driver can optionally fill in if it supports auto-configuration. A low-level driver that supports auto-configuration of {PCI,USB} devices calls the existing comedi_{pci,usb}_auto_config() when it wishes to auto-configure a freshly probed device (maybe after loading firmware). This will call the new '->attach_{pci,usb}()' hook if the driver has defined it, otherwise it will fall back to calling the '->attach()' hook as before. The '->attach_{pci,usb}()' hook gets a pointer to the struct comedi_device and a pointer to the struct {pci_dev,usb_interface} and can figure out the {PCI,USB} device details for itself. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-30 17:15:01 +01:00