Re: [PATCH v3 3/3] iio: accel: bmc150: use iio_push_to_buffers_with_ts()

[Jonathan Cameron]

On Mon, 31 Aug 2026 10:00:47 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:

> On Mon, Aug 31, 2026 at 01:27:28AM +0100, Jonathan Cameron wrote:
> > On Thu, 27 Aug 2026 10:08:07 +0300
> > Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:  
> > > On Tue, Aug 25, 2026 at 02:21:56PM +0530, Yash Suthar wrote:  
> > > > Replace deprecated iio_push_to_buffers_with_timestamp() with
> > > > iio_push_to_buffers_with_ts() to allow source size runtime checks.    
> > > 
> > > With this you might want to use IIO_DECLARE_DMA_BUFFER_WITH_TS() in the  
> 
> (For the record, I put it as "might".)
> 
> > > definition of the scan buffer.
> > >   
> > Why?  The structure used is: 
> > 	struct {
> >  		__le16 channels[3];
> >  		aligned_s64 ts;
> >  	} scan __aligned(IIO_DMA_MINALIGN);
> > 
> > So given we never let things get enabled with just timestamp, the timestamp
> > and channels always end up in the places the structure describes.  
> 
> OK! I personally consider the macro a bit more robust in the cases when
> we _might_ have new HW to support where it will be the case.

Ah, I kind of get that but doesn't worry me too much.

They will need to modify the structure and then we'll spot it.
It isn't a source of bugs if it does go wrong, just inelegant
as the structure kind of implies the timestamp is in a different
place from where ends up.

Maybe this is one for a maintainers profile that hopefully the
AI bots will then use to monitor this for us ;)

Jonathan


> 
> > Where that is the case, I much prefer this to the magic buffer with enough
> > elements of the channel type on the end.  
> 
> No objections.
>