mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>
To: "jic23@kernel.org" <jic23@kernel.org>,
	"Tachici, Alexandru" <Alexandru.Tachici@analog.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH v2] iio: industrialio-core: Fix debugfs read
Date: Mon, 2 Mar 2020 07:05:32 +0000	[thread overview]
Message-ID: <5c0b7ceca6ed35e46474de081d148e8c2fb9d071.camel@analog.com> (raw)
In-Reply-To: <20200301195622.0dfa31fc@archlinux>

On Sun, 2020-03-01 at 19:56 +0000, Jonathan Cameron wrote:
> [External]
> 
> On Fri, 21 Feb 2020 14:06:55 +0200
> Alexandru Tachici <alexandru.tachici@analog.com> wrote:
> 
> > Currently iio_debugfs_read_reg calls debugfs_reg_access
> > every time it is ran. Reading the same hardware register
> > multiple times during the same reading of a debugfs file
> > can cause unintended effects.
> > 
> > For example for each: cat iio:device0/direct_reg_access
> > the file_operations.read function will be called at least
> > twice. First will return the full length of the string in
> > bytes  and the second will return 0.
> > 
> > This patch makes iio_debugfs_read_reg to call debugfs_reg_access
> > only when the user's buffer position (*ppos) is 0. (meaning
> > it is the beginning of a new reading of the debugfs file).
> > 
> > Fixes: e553f182d55b ("staging: iio: core: Introduce debugfs support, add
> > support for direct register access")
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
> 
> I'm going to take this one via the slow path to give it a bit of time
> to soak in linux-next.   I think we are fine for unexpected side effects
> but it's been there for a long time so we can take this slowly.

No hurry from us.
This one has been showing-up randomly when trying to use the debugfs interface
for (well...) debugging.
Most of the times the double-read [of regs] is fine; so this issue can go un-
noticed.
But in cases like reading a FIFO for debug purposes [I know this sounds a bit
like an abuse, but it is being read from a reg], the double-read drops some
values.
And that makes some support more difficult.

> 
> Applied to the togreg branch of iio.git and pushed out as testing for
> the autobuilders to play with it.
> 
> Thanks,
> 
> Jonathan
> 
> > ---
> >  drivers/iio/industrialio-core.c | 15 +++++++++++----
> >  include/linux/iio/iio.h         |  2 ++
> >  2 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-
> > core.c
> > index 65ff0d067018..c4d5104934fc 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -301,11 +301,14 @@ static ssize_t iio_debugfs_read_reg(struct file *file,
> > char __user *userbuf,
> >  			      size_t count, loff_t *ppos)
> >  {
> >  	struct iio_dev *indio_dev = file->private_data;
> > -	char buf[20];
> >  	unsigned val = 0;
> > -	ssize_t len;
> >  	int ret;
> >  
> > +	if (*ppos > 0)
> > +		return simple_read_from_buffer(userbuf, count, ppos,
> > +					       indio_dev->read_buf,
> > +					       indio_dev->read_buf_len);
> > +
> >  	ret = indio_dev->info->debugfs_reg_access(indio_dev,
> >  						  indio_dev->cached_reg_addr,
> >  						  0, &val);
> > @@ -314,9 +317,13 @@ static ssize_t iio_debugfs_read_reg(struct file *file,
> > char __user *userbuf,
> >  		return ret;
> >  	}
> >  
> > -	len = snprintf(buf, sizeof(buf), "0x%X\n", val);
> > +	indio_dev->read_buf_len = snprintf(indio_dev->read_buf,
> > +					   sizeof(indio_dev->read_buf),
> > +					   "0x%X\n", val);
> >  
> > -	return simple_read_from_buffer(userbuf, count, ppos, buf, len);
> > +	return simple_read_from_buffer(userbuf, count, ppos,
> > +				       indio_dev->read_buf,
> > +				       indio_dev->read_buf_len);
> >  }
> >  
> >  static ssize_t iio_debugfs_write_reg(struct file *file,
> > diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> > index 862ce0019eba..eed58ed2f368 100644
> > --- a/include/linux/iio/iio.h
> > +++ b/include/linux/iio/iio.h
> > @@ -568,6 +568,8 @@ struct iio_dev {
> >  #if defined(CONFIG_DEBUG_FS)
> >  	struct dentry			*debugfs_dentry;
> >  	unsigned			cached_reg_addr;
> > +	char				read_buf[20];
> > +	unsigned int			read_buf_len;
> >  #endif
> >  };
> >  

      reply	other threads:[~2020-03-02  7:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 12:06 Alexandru Tachici
2020-03-01 19:56 ` Jonathan Cameron
2020-03-02  7:05   ` Ardelean, Alexandru [this message]

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=5c0b7ceca6ed35e46474de081d148e8c2fb9d071.camel@analog.com \
    --to=alexandru.ardelean@analog.com \
    --cc=Alexandru.Tachici@analog.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®