All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>
Cc: "ardeleanalex@gmail.com" <ardeleanalex@gmail.com>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [RFC][PATCH] iio: buffer: Don't allow buffers without any channels enabled to be activated
Date: Sat, 21 Mar 2020 18:21:44 +0000	[thread overview]
Message-ID: <20200321182144.4c3226ee@archlinux> (raw)
In-Reply-To: <3c2ea62e060ae260536766c3ebdd7fe6a1ab5725.camel@analog.com>

On Fri, 20 Mar 2020 11:16:12 +0000
"Ardelean, Alexandru" <alexandru.Ardelean@analog.com> wrote:

> On Fri, 2020-03-20 at 11:55 +0100, Lars-Peter Clausen wrote:
> > On 3/20/20 11:40 AM, Alexandru Ardelean wrote:  
> > > From: Lars-Peter Clausen <lars@metafoo.de>
> > > 
> > > Before activating a buffer make sure that at least one channel is enabled.
> > > Activating a buffer with 0 channels enabled doesn't make too much sense and
> > > disallowing this case makes sure that individual driver don't have to add
> > > special case code to handle it.
> > > 
> > > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > > ---
> > > 
> > > * Found this relic-patch in our tree, from 6 years ago:
> > >    https://github.com/analogdevicesinc/linux/commit/6d680e49d459c
> > >    It got moved around a bit, and this is the current form in the ADI tree.
> > >    So, this is also a bit of an RFC, but if the idea is valid, maybe it's
> > >    worth considering upstream. I don't know of any arguments against it,
> > >    but I could be surprised.  
> > 
> > Hm, a bit weird that this one never made it upstream considering how 
> > simple it is.
> > 
> > Did you check that the issue still occurs? I can't see anything in the 
> > code that prevents it, but who knows, maybe it was fixed by something else.  
> 
> i did not think to check behavior/issues;
> i'll try to make some time for that;

I can't immediately think of anything that would stop this case.

However, good if you could confirm it.  (I don't have a setup running
right now to test against)


> i caught this one while diff-ing the upstream & ADI trees, and i needed to dig a
> bit more into the ADI git history on it;
> 
> i was a bit puzzled for a while, because some rework patches were upstreamed
> without this patch:
> 
> https://lore.kernel.org/linux-iio/55585CAA.6000506@kernel.org/
> https://lore.kernel.org/linux-iio/5560685A.5060504@kernel.org/
> 
> i also did not find any discussions/upstream attempt for this patch particularly
> 
> so, it was easier for me just to RFC this
> 
> >   
> > >   drivers/iio/industrialio-buffer.c | 6 ++++++
> > >   1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> > > buffer.c
> > > index 4ada5592aa2b..f222a118d0d3 100644
> > > --- a/drivers/iio/industrialio-buffer.c
> > > +++ b/drivers/iio/industrialio-buffer.c
> > > @@ -1031,6 +1031,12 @@ static int __iio_update_buffers(struct iio_dev
> > > *indio_dev,
> > >   		return ret;
> > >   
> > >   	if (insert_buffer) {
> > > +		if (bitmap_empty(insert_buffer->scan_mask,
> > > +			indio_dev->masklength)) {
> > > +			ret = -EINVAL;
> > > +			goto err_free_config;
> > > +		}  
> > 
> > Since the check is so simple it might make sense to do it as the very 
> > first thing before iio_verify_update().  
> 
> works for me;
> 
> >   
> > > +
> > >   		ret = iio_buffer_request_update(indio_dev, insert_buffer);
> > >   		if (ret)
> > >   			goto err_free_config;
> > >   


  reply	other threads:[~2020-03-21 18:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20 10:40 [RFC][PATCH] iio: buffer: Don't allow buffers without any channels enabled to be activated Alexandru Ardelean
2020-03-20 10:55 ` Lars-Peter Clausen
2020-03-20 11:16   ` Ardelean, Alexandru
2020-03-21 18:21     ` Jonathan Cameron [this message]
2020-03-21 21:44       ` Andy Shevchenko
2020-03-25  8:17       ` Ardelean, Alexandru
2020-03-25  8:23         ` Ardelean, Alexandru
2020-03-25 10:01 ` [PATCH v2] " Alexandru Ardelean
2020-03-25 10:12   ` Ardelean, Alexandru
2020-03-25 15:57   ` Andy Shevchenko
2020-03-26  7:42     ` Ardelean, Alexandru
2020-03-26  7:44       ` Lars-Peter Clausen
2020-03-26  7:46         ` Ardelean, Alexandru
2020-03-26  9:30 ` [PATCH v3] " Alexandru Ardelean
2020-03-28 13:13   ` 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=20200321182144.4c3226ee@archlinux \
    --to=jic23@kernel.org \
    --cc=alexandru.Ardelean@analog.com \
    --cc=ardeleanalex@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.