On Thu, Sep 26, 2013 at 1:58 PM, Mark Brown broonie@kernel.org wrote:
On Thu, Sep 26, 2013 at 12:58:27PM -0700, Andrey Smirnov wrote:
On Thu, Sep 26, 2013 at 12:43 PM, Mark Brown broonie@kernel.org wrote:
What exactly is the locking you're talking about here?
I am talking about locking specific for si476x MFD device that is hadled by si476x_core_lock / si476x_core_unlock. The code before the patch has both externally exposed functions via V4L2 driver and SoC driver obtain said lock for the duration of their interaction with the device. The patch appears to remove lock acquisition for SoC functions.
But what exactly are these locks supposed to be protecting?
The way the code is written it looks like the lock is being held to ensure there's no race due to a power state change.
That lock is being held to prevent device access contention between all of the code that can be triggered to be executed via V4L2 ioctl API and SoC API. As an example, I can open the radio device and start tuning it using corresponding ioctl, meanwhile, parallel to that process my other code is trying to change the sample rate of the codec. To prevent those two from clashes both of them try to acquire "core lock" with si476x_core_lock before the start doing anything with chip/MFD.
In what way might these things conflict? What are the clashes you are concerned about?
That lock serves the purpose of making sure that si476x_core_send_command, calls to which all the rest of the functions boil down to, is not executed in parallel to itself. So I am concerned that with the lock acquisition removal it would be possible to make that condition happen.