On 09/03/16 20:06, Alison Schofield wrote: > On Sat, Mar 05, 2016 at 06:02:36PM +0000, Jonathan Cameron wrote: >> On 02/03/16 13:28, Lars-Peter Clausen wrote: >>> On 03/01/2016 08:02 PM, Alison Schofield wrote: >>>> It is often the case that the driver wants to be sure a device stays >>>> in direct mode while it is executing a task or series of tasks. To >>>> accomplish this today, the driver performs this sequence: 1) take the >>>> device state lock, 2)verify it is not in a buffered mode, 3) execute >>>> some tasks, and 4) release that lock. >>>> >>>> This patch introduces a pair of helper functions that simplify these >>>> steps and make it more semantically expressive. >>>> >>>> iio_claim_direct_mode() >>>> If the device is not in any buffered mode it is guaranteed >>>> to stay that way until iio_release_direct_mode() is called. >>>> >>>> iio_release_direct_mode() >>>> Release the claim. Device is no longer guaranteed to stay >>>> in direct mode. >>>> >>>> Signed-off-by: Alison Schofield <amsfield22@xxxxxxxxx> >>> >>> Looks basically good. >> Agreed - nothing to add from me to what Lars has covered here. >> Nice to 'hide' the accesses to mlock as well as will cut out the desire >> to 'abuse it'. Amusingly we only just 'fixed' the docs to to say this >> element of iio_dev was usable by drivers. Once we have these new functions >> in use throughout the tree, we will want to flip that back again to internal >> only. >> >> Jonathan >> > Thanks for the review (& Lars too) > > Thinking about your note about flipping the mlock field back to > INTERNAL (from DRIVER), this change, even when it's applied to > all relevant instances, doesn't get us all the way there. > > While these claim/release functions will remove direct access to mlock > where a driver wants to hold direct mode, the drivers are grabbing > mlock for other reasons also. (too many reasons/instances for me to > quickly understand or summarize) > > I'm willing to look at it further and comment if that's helpful. It would certainly be interesting to evaluate this. I suspect that most are either in some obscure way connected to the mode or are 'misusing' the lock for more general purposes where a driver specific lock would make more sense. Jonathan > > alisons > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
