linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>,
	Alison Schofield <amsfield22@gmail.com>,
	outreachy-kernel@googlegroups.com
Cc: knaack.h@gmx.de, pmeerw@pmeerw.net, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org, Michael.Hennerich@analog.com,
	gregkh@linuxfoundation.org, devel@driverdev.osuosl.org
Subject: Re: [RFC PATCH 1/2] iio: core: implement iio_{claim|release}_direct_mode()
Date: Sat, 5 Mar 2016 18:02:36 +0000	[thread overview]
Message-ID: <56DB1F3C.8020302@kernel.org> (raw)
In-Reply-To: <56D6EA82.8090601@metafoo.de>

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@gmail.com>
> 
> 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
> 
>> ---
>>  drivers/iio/industrialio-core.c | 39 +++++++++++++++++++++++++++++++++++++++
>>  include/linux/iio/iio.h         |  2 ++
>>  2 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
>> index 70cb7eb..f6f0c89 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -25,6 +25,7 @@
>>  #include <linux/slab.h>
>>  #include <linux/anon_inodes.h>
>>  #include <linux/debugfs.h>
>> +#include <linux/mutex.h>
>>  #include <linux/iio/iio.h>
>>  #include "iio_core.h"
>>  #include "iio_core_trigger.h"
>> @@ -1375,6 +1376,44 @@ void devm_iio_device_unregister(struct device *dev, struct iio_dev *indio_dev)
>>  }
>>  EXPORT_SYMBOL_GPL(devm_iio_device_unregister);
>>  
>> +/**
>> + * iio_claim_direct_mode - Keep device in direct mode
>> + * @indio_dev:	the iio_dev associated with the device
>> + *
>> + * If the device is in direct mode it is guaranteed to
>> + * stay that way until iio_release_direct_mode() is called.
>> + *
>> + * Use with iio_release_direct_mode()
>> + *
>> + * Returns: 0 on success, -EINVAL on failure
>> + */
>> +int iio_claim_direct_mode(struct iio_dev *indio_dev)
> 
> To be consistent with the reset of the API I'd use the iio_device_... prefix
> here, same for the release function.
> 
>> +{
>> +	mutex_lock(&indio_dev->mlock);
>> +
>> +	if (iio_buffer_enabled(indio_dev)) {
>> +		mutex_unlock(&indio_dev->mlock);
>> +		return -EINVAL;
> 
> -EINVAL doesn't make much sense here, -EBUSY is better.
> 
>> +	}
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(iio_claim_direct_mode);
>>


  reply	other threads:[~2016-03-05 18:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01 18:58 [RFC PATCH 0/2] iio: introduce iio_{claim|release}_direct_mode() Alison Schofield
2016-03-01 19:02 ` [RFC PATCH 1/2] iio: core: implement iio_{claim|release}_direct_mode() Alison Schofield
2016-03-02 13:28   ` Lars-Peter Clausen
2016-03-05 18:02     ` Jonathan Cameron [this message]
2016-03-09 20:06       ` Alison Schofield
2016-03-09 20:23         ` Jonathan Cameron
2016-03-01 19:03 ` [RFC PATCH 2/2] staging: iio: adc7192: use iio_{claim|release}_direct_mode() Alison Schofield
2016-03-09 19:25 ` [RFC PATCH v2 0/2] iio: introduce iio_device_{claim|release}_direct_mode() Alison Schofield
2016-03-09 19:30   ` [RFC PATCH v2 1/2] iio: core: implement iio_device_{claim|release}_direct_mode() Alison Schofield
2016-03-12 11:18     ` Jonathan Cameron
2016-03-09 19:30   ` [RFC PATCH v2 2/2] staging: iio: ad7192: use iio_device_{claim|release}_direct_mode() Alison Schofield
2016-03-12 11:21     ` Jonathan Cameron
2016-03-12 11:25       ` Jonathan Cameron
2016-03-12 11:16   ` [RFC PATCH v2 0/2] iio: introduce iio_device_{claim|release}_direct_mode() Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56DB1F3C.8020302@kernel.org \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=amsfield22@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=outreachy-kernel@googlegroups.com \
    --cc=pmeerw@pmeerw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).