Re: [PATCH 00/20] IIO: Tidying up timestamp alignment markings.

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 15 Dec 2024 23:18:14 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Sun, Dec 15, 2024 at 06:28:51PM +0000, Jonathan Cameron wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > 
> > I haven't +CC everyone relevant as that would be too long a list
> > and these are mostly entirely mechanical changes that just need
> > someone to sanity check I didn't do anything stupid.
> > 
> > This combines several related types of change:
> > 
> > - Some 'fixes'. These aren't actual bugs but more places where
> >   the code relies on factors it shouldn't such as what architecture
> >   the driver is running on, or padding of the wrong element happening
> >   to always make enough room.
> > - Now we have aligned_s64, use that to replace all the remaining
> >   s64 timestamp __aligned(8) instances in IIO.
> >   This is both cleaner and hopefully less prone to confusing static
> >   analysis tools.
> > - Change the timestamp type in iio_push_to_buffers_with_timestamp() to s64.
> >   This is an entirely in kernel interface. It's data is pushed to user space
> >   in many case but by a rather indirect route, so I think it is more
> >   appropriate to switch this to s64 which is the type of almost all the
> >   values passed into it. Note a follow up series may tidy up some
> >   local variables that are of the int64_t type.
> > - Change the few int64_t timestamp __aligned(8) cases to aligned_s64.
> >   This is mostly a consistency thing to avoid confusion if a new author
> >   is trying to figure out what types they should use.  Better to have
> >   one answer than a mixture.
> > 
> > There is one other IIO driver hiding over in media that will be modified
> > by a separate patch because I want to add some more info to that and
> > a more specific CC list.  
> 
> I briefly looked at most of the patches and haven't noticed any potential
> issues, all seems like a straightforward conversion. Hence
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> for all, except 15 and 19.
> 
> Patch 15 has got a few minor comments (and to accent on that I'm not sure about
> my offer for sizeof(), using direct variable might make it inconsistent in this
> case, because the following line uses explicit type instead of typeof(), and
> using the latter makes the code unreadable).
> 
> Patch 19 seems correct to me, but I'm not going to give a tag to be on the safe
> side.

Thanks, I've applied all but 15 and 19 (which could do with more eyes and will
be more obvious in a v2 with just two patches!)

Will tidy up 15 and send out a v2 shortly.

Thanks,

Jonathan

>