[0/7] Adis IRQ fixes and minor improvements

Message

Nuno Sa April 13, 2021, 11:20 a.m. UTC

The primary goal of this series was to fix the return value on some
trigger handlers as spotted in [1]. While doing it, I found some minor
improvements that I think are simple enough to include in this series.

As for the first 2 patches, I opted to not do any functional change so
I'm keeping the 'if (!adis->buffer)' check. However, 'adis-buffer' is
allocated in 'update_scan_mode' hook which means we should be sure that
the buffer is allocated and the check is really not needed. I did not
went into the details but is there any way for the trigger handler to be
called before the 'update_scan_mode' hook? If not, I'm happy in sending
a v2 where we just remove the 'if'...

[1]: https://marc.info/?l=linux-iio&m=161815197426882&w=2

Nuno Sa (7):
  iio: adis_buffer: do not return ints in irq handlers
  iio: adis16400: do not return ints in irq handlers
  iio: adis16475: do not return ints in irq handlers
  iio: adis16475: re-set max spi transfer
  iio: adis_buffer: check return value on page change
  iio: adis_buffer: don't push data to buffers on failure
  iio: adis_buffer: update device page after changing it

 drivers/iio/imu/adis16400.c   |  3 ++-
 drivers/iio/imu/adis16475.c   |  6 ++++--
 drivers/iio/imu/adis_buffer.c | 20 +++++++++++++-------
 3 files changed, 19 insertions(+), 10 deletions(-)

Comments

Lars-Peter Clausen April 14, 2021, 8:37 a.m. UTC | #1

On 4/13/21 1:20 PM, Nuno Sa wrote:
> The primary goal of this series was to fix the return value on some
> trigger handlers as spotted in [1]. While doing it, I found some minor
> improvements that I think are simple enough to include in this series.
>
> As for the first 2 patches, I opted to not do any functional change so
> I'm keeping the 'if (!adis->buffer)' check. However, 'adis-buffer' is
> allocated in 'update_scan_mode' hook which means we should be sure that
> the buffer is allocated and the check is really not needed. I did not
> went into the details but is there any way for the trigger handler to be
> called before the 'update_scan_mode' hook? If not, I'm happy in sending
> a v2 where we just remove the 'if'...

I do remember that the check was deliberate. I do remember of thinking 
about whether we need this and feeling uncomfortable about not having 
the check. But I think it is more a instance of defensive programming 
rather than actually being required.

It was less about the trigger being called before update_scan_mode, but 
in case it gets called if the allocation in update_scan_mode fails. But 
I think this should not be possible. So it is probably safe to remove it.

- Lars