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
> > };
> >
prev parent 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®