On Tue, 2020-02-25 at 22:41 +0530, Rohit Sarkar wrote: > Hi, > Could someone explain why using indio_dev->mlock directly is a bad idea? > Further examples of cases where it cannot be replaced will be helpful > Jonathan may add more here. But in general, each driver should define it's own explicit lock if it needs to. Some drivers need explicit locking, some don't. A lot of other frameworks already define locks already. Like, for example, when an IIO driver uses some SPI transfers, the SPI framework already uses some locks. So, you don't typically need extra locking; which for some IIO drivers translates to: no extra explicit locking. I guess Jonathan also wants to move the mlock to be used only in the IIO framework. In some cases, if drivers use this mlock, and the framework uses it, you can end up trying to acquire the same mlock twice, which can end-up in a deadlock. These things can sometimes slip through the code-review. I guess the docs need a bit of update. Because: * @mlock: [DRIVER] lock used to prevent simultaneous device state * changes I think it should be converted to [INTERN] > Thanks, > Rohit >
