| Message ID | 20210413112105.69458-5-nuno.sa@analog.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Adis IRQ fixes and minor improvements | expand |
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. > - if (ret) > + if (ret) { > + adis->spi->max_speed_hz = cached_spi_speed_hz; > goto check_burst32; > + } > > adis->spi->max_speed_hz = cached_spi_speed_hz; [1] > buffer = adis->buffer; > -- > 2.31.1 >
> -----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)...
> -----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...
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 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). I'm going to hold this series for now on basis we should resolve this whilst here. Jonathan
> -----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/ - Nuno Sá
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á
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); - if (ret) + if (ret) { + adis->spi->max_speed_hz = cached_spi_speed_hz; goto check_burst32; + } adis->spi->max_speed_hz = cached_spi_speed_hz; buffer = adis->buffer;
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(-)