On Wed, Feb 26, 2020 at 06:54:21AM +0000, Ardelean, Alexandru wrote: > 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. This makes sense > 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 > > As a follow up would I be right to assume that as long as the mlock is not being in the IIO framework, explicit locking should be the way to go? Thanks, Rohit
