v1 was a single patch converting the two push sites to
iio_push_to_buffers_with_ts(). Reviewing it, Jonathan pointed out that
the driver carries two separate staging areas holding the same thing
(buffer[8] and the scan struct), and asked to fold the cleanup into this
set.

So v2 is a two-patch series: patch 1 drops the redundant buffer and
routes the one-shot read and the triggered handler through scan, and
patch 2 does the deprecated-API conversion, now with a single buffer to
push at both sites.

Changes in v2:
- New patch 1: drop buffer[8], use scan for the one-shot read and the
  triggered handler, move IIO_DMA_MINALIGN onto scan (Jonathan)
- Patch 2 now pushes data->scan at both sites instead of data->buffer

v1: https://lore.kernel.org/linux-iio/20260818155635.8367-1-grondon@gmail.com/

Gabriel Rondon (2):
  iio: accel: kionix-kx022a: use scan struct for one-shot and trigger
    reads
  iio: accel: kionix-kx022a: use iio_push_to_buffers_with_ts()

 drivers/iio/accel/kionix-kx022a.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

-- 
2.50.1 (Apple Git-155)

On Tue, Aug 18, 2026 at 10:51:20PM +0100, Gabriel Rondon wrote:
> v1 was a single patch converting the two push sites to
> iio_push_to_buffers_with_ts(). Reviewing it, Jonathan pointed out that
> the driver carries two separate staging areas holding the same thing
> (buffer[8] and the scan struct), and asked to fold the cleanup into this
> set.
> 
> So v2 is a two-patch series: patch 1 drops the redundant buffer and
> routes the one-shot read and the triggered handler through scan, and
> patch 2 does the deprecated-API conversion, now with a single buffer to
> push at both sites.

Good job!
Assuming my comments are being addressed,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

On Tue, 18 Aug 2026 22:51:20 +0100
Gabriel Rondon <grondon@gmail.com> wrote:

> v1 was a single patch converting the two push sites to
> iio_push_to_buffers_with_ts(). Reviewing it, Jonathan pointed out that
> the driver carries two separate staging areas holding the same thing
> (buffer[8] and the scan struct), and asked to fold the cleanup into this
> set.
> 
> So v2 is a two-patch series: patch 1 drops the redundant buffer and
> routes the one-shot read and the triggered handler through scan, and
> patch 2 does the deprecated-API conversion, now with a single buffer to
> push at both sites.
> 
> Changes in v2:
> - New patch 1: drop buffer[8], use scan for the one-shot read and the
>   triggered handler, move IIO_DMA_MINALIGN onto scan (Jonathan)
> - Patch 2 now pushes data->scan at both sites instead of data->buffer
> 
Nice.  All looks good to me, so I'll queue it up.

Applied to the testing branch of iio.git which will be rebased on rc1 once
available.

Note that there is plenty of time for additional feedback, tags or indeed
me to drop it again if someone spots something I missed.

Thanks,

Jonathan

> v1: https://lore.kernel.org/linux-iio/20260818155635.8367-1-grondon@gmail.com/
> 
> Gabriel Rondon (2):
>   iio: accel: kionix-kx022a: use scan struct for one-shot and trigger
>     reads
>   iio: accel: kionix-kx022a: use iio_push_to_buffers_with_ts()
> 
>  drivers/iio/accel/kionix-kx022a.c | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
>

On 19/08/2026 03:09, Jonathan Cameron wrote:
> On Tue, 18 Aug 2026 22:51:20 +0100
> Gabriel Rondon <grondon@gmail.com> wrote:
> 
>> v1 was a single patch converting the two push sites to
>> iio_push_to_buffers_with_ts(). Reviewing it, Jonathan pointed out that
>> the driver carries two separate staging areas holding the same thing
>> (buffer[8] and the scan struct), and asked to fold the cleanup into this
>> set.
>>
>> So v2 is a two-patch series: patch 1 drops the redundant buffer and
>> routes the one-shot read and the triggered handler through scan, and
>> patch 2 does the deprecated-API conversion, now with a single buffer to
>> push at both sites.
>>
>> Changes in v2:
>> - New patch 1: drop buffer[8], use scan for the one-shot read and the
>>    triggered handler, move IIO_DMA_MINALIGN onto scan (Jonathan)
>> - Patch 2 now pushes data->scan at both sites instead of data->buffer
>>
> Nice.  All looks good to me, so I'll queue it up.
> 
> Applied to the testing branch of iio.git which will be rebased on rc1 once
> available.
> 
> Note that there is plenty of time for additional feedback, tags or indeed
> me to drop it again if someone spots something I missed.

Ah, Jonathan was quick and efficient :)
I'll drop my comments to 'nits' in order to not generate more work for 
Jonathan. Hence, acting on my comments is not required.

-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

On Wed, Aug 19, 2026 at 08:15:40AM +0300, Matti Vaittinen wrote:
> On 19/08/2026 03:09, Jonathan Cameron wrote:
> > On Tue, 18 Aug 2026 22:51:20 +0100
> > Gabriel Rondon <grondon@gmail.com> wrote:
> > 
> > > v1 was a single patch converting the two push sites to
> > > iio_push_to_buffers_with_ts(). Reviewing it, Jonathan pointed out that
> > > the driver carries two separate staging areas holding the same thing
> > > (buffer[8] and the scan struct), and asked to fold the cleanup into this
> > > set.
> > > 
> > > So v2 is a two-patch series: patch 1 drops the redundant buffer and
> > > routes the one-shot read and the triggered handler through scan, and
> > > patch 2 does the deprecated-API conversion, now with a single buffer to
> > > push at both sites.
> > > 
> > > Changes in v2:
> > > - New patch 1: drop buffer[8], use scan for the one-shot read and the
> > >    triggered handler, move IIO_DMA_MINALIGN onto scan (Jonathan)
> > > - Patch 2 now pushes data->scan at both sites instead of data->buffer
> > > 
> > Nice.  All looks good to me, so I'll queue it up.
> > 
> > Applied to the testing branch of iio.git which will be rebased on rc1 once
> > available.
> > 
> > Note that there is plenty of time for additional feedback, tags or indeed
> > me to drop it again if someone spots something I missed.
> 
> Ah, Jonathan was quick and efficient :)
> I'll drop my comments to 'nits' in order to not generate more work for

And I, in the opposite, insist on mine against patch 1 as I consider that that
makes code easier to read and follow.

> Jonathan. Hence, acting on my comments is not required.

-- 
With Best Regards,
Andy Shevchenko

On Wed, 19 Aug 2026 10:18:44 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Aug 19, 2026 at 08:15:40AM +0300, Matti Vaittinen wrote:
> > On 19/08/2026 03:09, Jonathan Cameron wrote:  
> > > On Tue, 18 Aug 2026 22:51:20 +0100
> > > Gabriel Rondon <grondon@gmail.com> wrote:
> > >   
> > > > v1 was a single patch converting the two push sites to
> > > > iio_push_to_buffers_with_ts(). Reviewing it, Jonathan pointed out that
> > > > the driver carries two separate staging areas holding the same thing
> > > > (buffer[8] and the scan struct), and asked to fold the cleanup into this
> > > > set.
> > > > 
> > > > So v2 is a two-patch series: patch 1 drops the redundant buffer and
> > > > routes the one-shot read and the triggered handler through scan, and
> > > > patch 2 does the deprecated-API conversion, now with a single buffer to
> > > > push at both sites.
> > > > 
> > > > Changes in v2:
> > > > - New patch 1: drop buffer[8], use scan for the one-shot read and the
> > > >    triggered handler, move IIO_DMA_MINALIGN onto scan (Jonathan)
> > > > - Patch 2 now pushes data->scan at both sites instead of data->buffer
> > > >   
> > > Nice.  All looks good to me, so I'll queue it up.
> > > 
> > > Applied to the testing branch of iio.git which will be rebased on rc1 once
> > > available.
> > > 
> > > Note that there is plenty of time for additional feedback, tags or indeed
> > > me to drop it again if someone spots something I missed.  
> > 
> > Ah, Jonathan was quick and efficient :)

Hmm. Worried about too many thing floating around is more accurate.

> > I'll drop my comments to 'nits' in order to not generate more work for  
> 
> And I, in the opposite, insist on mine against patch 1 as I consider that that
> makes code easier to read and follow.
True enough - so tweaked

Jonathan

> 
> > Jonathan. Hence, acting on my comments is not required.  
>