Thanks, it made me think about it deeper...
On 20. 7. 8. 오전 12:07, Andy Shevchenko wrote:
On Tue, Jul 7, 2020 at 5:03 PM Sungbo Eo <mans0n@xxxxxxxxxx> wrote:
On 20. 7. 6. 오후 9:00, Andy Shevchenko wrote:
...
But I don't really understand what mutex does here. The driver does not
need consecutive commands, it only sends/receives only one byte at a
time. And AFAIK each i2c_smbus function is already protected by a mutex.
So what should be exactly inside the lock? Should we protect the output
buffer as well? I'm not an expert on this so please enlighten me.
There are questions, answering them will give you a solution:
- Since we have two functions doing i2c communications, can they
clash? If so, does the i2c framework guarantee the serialisation?
I think it does.
- Since we have a shared resource (buf), can accessors clash? How do
we guarantee serialization?
But the output buffer should be tied to the i2c operations. So I guess
it requires a mutex here.
pca9570_get() does not access gpio->out so it does not need to be locked.
On the other hand, the whole pca9570_set() function should be protected,
from reading gpio->out to rewriting to gpio->out. So pca9570_write()
error check should be inside the lock as well. Am I right?
Thanks.
