On 30/03/15 17:47, Hartley Sweeten wrote:
On Friday, March 27, 2015 8:13 AM, Ian Abbott wrote:
`comedi_event()` is called from low-level drivers to handle comedi
asynchronous command event flags. As a safety check, it checks the
subdevice's "run" flags to make sure an asynchronous command is running.
It can also change the run flags to mark the command as no longer
running (possibly also marking it as terminated with an error).
Checking the runflags and modifying them involves two uses of the
subdevice's spin-lock. It seems better to do it with a single use of
the spin-lock. This also avoids possible interactions with
`do_become_nonbusy()`.
Acquire the subdevice's spin-lock at the start of `comedi_event()` and
release it near the end, before a possible call to `kill_fasync()` (but
after it's parameter values have been determined).
Add and make use of few new inline helper functions:
* `__comedi_clear_subdevice_runflags()` -- clears some run flags without
using the spin-lock
* `__comedi_set_subdevice_runflags()` -- sets some run flags without
using the spin-lock
* `__comedi_get_subdevice_runflags()` -- a spin-lockless version of
`comedi_get_subdevice_runflags()
* `__comedi_is_subdevice_running()` -- a spin-lockless version of
* `comedi_is_subdevice_running()`
Signed-off-by: Ian Abbott <abbotti@xxxxxxxxx>
Ian,
For completeness, the comedi_alloc_spriv() helper should probably use
__comedi_set_subdevice_runflags() to set the COMEDI_SRF_FREE_SPRIV
bit.
Regards,
Hartley
Good point. "drivers/staging/comedi/drivers.c" also reads the runflags
directly, so perhaps __comedi_clear_subdevice_runflags(),
__comedi_set_subdevice_runflags() and __comedi_get_subdevice_runflags()
should be placed in "drivers/staging/comedi/comedi_internal.h". Or we
could ditch all three of those inline functions as they are just simple
one-liners.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel