From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Sa, Nuno" <Nuno.Sa@analog.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Alexandru Ardelean <ardeleanalex@gmail.com>,
linux-iio <linux-iio@vger.kernel.org>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH 4/7] iio: adis16475: re-set max spi transfer
Date: Mon, 19 Apr 2021 16:41:32 +0100 [thread overview]
Message-ID: <20210419164132.0000714d@Huawei.com> (raw)
In-Reply-To: <CY4PR03MB311289981955B0889BE539F499499@CY4PR03MB3112.namprd03.prod.outlook.com>
On Mon, 19 Apr 2021 07:47:55 +0000
"Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> > -----Original Message-----
> > From: Jonathan Cameron <jic23@kernel.org>
> > Sent: Sunday, April 18, 2021 12:21 PM
> > To: Sa, Nuno <Nuno.Sa@analog.com>
> > Cc: Alexandru Ardelean <ardeleanalex@gmail.com>; linux-iio <linux-
> > iio@vger.kernel.org>; Hennerich, Michael
> > <Michael.Hennerich@analog.com>; Lars-Peter Clausen
> > <lars@metafoo.de>
> > Subject: Re: [PATCH 4/7] iio: adis16475: re-set max spi transfer
> >
> > [External]
> >
> > On Thu, 15 Apr 2021 08:16:30 +0000
> > "Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Sa, Nuno <Nuno.Sa@analog.com>
> > > > Sent: Thursday, April 15, 2021 9:54 AM
> > > > To: Alexandru Ardelean <ardeleanalex@gmail.com>
> > > > Cc: linux-iio <linux-iio@vger.kernel.org>; Jonathan Cameron
> > > > <jic23@kernel.org>; Hennerich, Michael
> > > > <Michael.Hennerich@analog.com>; Lars-Peter Clausen
> > > > <lars@metafoo.de>
> > > > Subject: RE: [PATCH 4/7] iio: adis16475: re-set max spi transfer
> > > >
> > > > [External]
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Alexandru Ardelean <ardeleanalex@gmail.com>
> > > > > Sent: Wednesday, April 14, 2021 9:29 AM
> > > > > To: Sa, Nuno <Nuno.Sa@analog.com>
> > > > > Cc: linux-iio <linux-iio@vger.kernel.org>; Jonathan Cameron
> > > > > <jic23@kernel.org>; Hennerich, Michael
> > > > > <Michael.Hennerich@analog.com>; Lars-Peter Clausen
> > > > > <lars@metafoo.de>
> > > > > Subject: Re: [PATCH 4/7] iio: adis16475: re-set max spi transfer
> > > > >
> > > > > [External]
> > > > >
> > > > > On Tue, Apr 13, 2021 at 5:45 PM Nuno Sa <nuno.sa@analog.com>
> > > > > wrote:
> > > > > >
> > > > > > In case 'spi_sync()' fails, we would be left with a max spi
> > transfer
> > > > > > which is not the one the user expects it to be. Hence, we need
> > to
> > > > re-
> > > > > set
> > > > > > it also in this error path.
> > > > > >
> > > > > > Fixes: fff7352bf7a3c ("iio: imu: Add support for adis16475")
> > > > > > Signed-off-by: Nuno Sa <nuno.sa@analog.com>
> > > > > > ---
> > > > > > drivers/iio/imu/adis16475.c | 4 +++-
> > > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/iio/imu/adis16475.c
> > > > b/drivers/iio/imu/adis16475.c
> > > > > > index 51b76444db0b..9dca7e506200 100644
> > > > > > --- a/drivers/iio/imu/adis16475.c
> > > > > > +++ b/drivers/iio/imu/adis16475.c
> > > > > > @@ -1067,8 +1067,10 @@ static irqreturn_t
> > > > > adis16475_trigger_handler(int irq, void *p)
> > > > > > adis->spi->max_speed_hz =
> > ADIS16475_BURST_MAX_SPEED;
> > > > > >
> > > > > > ret = spi_sync(adis->spi, &adis->msg);
> > > > >
> > > > > Purely stylistic here.
> > > > > But, the restore from the cached variable could be done here in a
> > > > > single line.
> > > > > So. just moving [1] here.
> > > >
> > > > You mean also doing it in the label? I thought about that and the
> > > > reason
> > > > why I didn't is that on a normal run, I want to reset the max freq as
> > > > soon
> > > > as possible so that if someone concurrently tries to read 'direct
> > mode'
> > > > attrs
> > > > gets the max freq. This was my reasoning but I admit that it's not
> > that
> > > > important so I will leave this to Jonathan's preference...
> > > >
> > > > Hmm now that I spoke about the concurrently access to IIO attr
> > and
> > > > being paranoid about
> > > > the compiler, I wonder if we should not use
> > > > WRITE_ONCE(adis->spi->max_speed_hz,
> > > > ADIS16475_BURST_MAX_SPEED)...
> > >
> > > Hmmm, actually WRITE_ONCE would not be any help since the spi
> > core
> > > does not use READ_ONCE. So, if we are going to be paranoid about
> > the
> > > compiler and load/store tearing, I guess the only safe way here is to
> > > acquire the adis lock [btw, I'm a bit paranoid with this stuff :)]...
> > >
> > > Anyways, arguably the likelihood for this to happen is really, really
> > small...
> >
> > Really small, but needs fixing. We shouldn't have a window in which
> > this
>
> Agreed!
>
> > can happen. So either we need to stop those attributes from reading
> > whilst
> > we are in buffered mode (via claim_direct_mode pattern) or we need
> > to put
> > a lock around this. As an alternative, could we use the speed_hz field
> > in appropriate spi_transfer structures to tweak in this path without
> > affecting others? That should make this concurrency problem an issue
> > for the spi core (which I'd assume handles this).
>
> Hmm, I like the 'speed_hz' approach as there's no reason to grab
> the lock because of a spi core tweak. As you said, with this, we push things
> to spi core. Going one step further, I think the most appropriate thing to do
> is actually come up with a new member in the 'adis_data' struct
> (like burst_max_speed_hz) and tweak the burst mode transfers accordingly in
> 'adis_update_scan_mode_burst()' (as there's no need to set this on every
> burst sample)...
>
> If we are going the above path, what would be your preference? To add the
> patches to this series? Or to just fix this patch and [1] and push another series
> with the above changes? Hmm, since [1] would also depend on this, I guess the
> later approach would be better?
>
> [1]: https://patchwork.kernel.org/project/linux-iio/patch/20210413092815.28626-1-nuno.sa@analog.com/
Make a new version of this series with the fix, then provide an update of [1]
that is probably going to be dependent on this series.
Given this is a fix, ideally we'll backport it which we don't need to do
for the new code introduced in [1].
Thanks,
Jonathan
>
> - Nuno Sá
next prev parent reply other threads:[~2021-04-19 15:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 11:20 [PATCH 0/7] Adis IRQ fixes and minor improvements Nuno Sa
2021-04-13 11:20 ` [PATCH 1/7] iio: adis_buffer: do not return ints in irq handlers Nuno Sa
2021-04-14 7:23 ` Alexandru Ardelean
2021-04-13 11:21 ` [PATCH 2/7] iio: adis16400: " Nuno Sa
2021-04-14 7:23 ` Alexandru Ardelean
2021-04-13 11:21 ` [PATCH 3/7] iio: adis16475: " Nuno Sa
2021-04-14 7:27 ` Alexandru Ardelean
2021-04-15 7:38 ` Sa, Nuno
2021-04-15 8:17 ` Alexandru Ardelean
2021-04-13 11:21 ` [PATCH 4/7] iio: adis16475: re-set max spi transfer Nuno Sa
2021-04-14 7:28 ` Alexandru Ardelean
2021-04-15 7:53 ` Sa, Nuno
2021-04-15 8:16 ` Sa, Nuno
2021-04-18 10:20 ` Jonathan Cameron
2021-04-19 7:47 ` Sa, Nuno
2021-04-19 15:41 ` Jonathan Cameron [this message]
2021-04-13 11:21 ` [PATCH 5/7] iio: adis_buffer: check return value on page change Nuno Sa
2021-04-14 7:34 ` Alexandru Ardelean
2021-04-15 7:55 ` Sa, Nuno
2021-04-13 11:21 ` [PATCH 6/7] iio: adis_buffer: don't push data to buffers on failure Nuno Sa
2021-04-14 7:35 ` Alexandru Ardelean
2021-04-15 7:56 ` Sa, Nuno
2021-04-13 11:21 ` [PATCH 7/7] iio: adis_buffer: update device page after changing it Nuno Sa
2021-04-14 7:38 ` Alexandru Ardelean
2021-04-15 7:58 ` Sa, Nuno
2021-04-15 8:20 ` Alexandru Ardelean
2021-04-14 8:37 ` [PATCH 0/7] Adis IRQ fixes and minor improvements Lars-Peter Clausen
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=20210419164132.0000714d@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=Nuno.Sa@analog.com \
--cc=ardeleanalex@gmail.com \
--cc=jic23@kernel.org \
--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 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).