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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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.

-- 
With Best Regards,
Andy Shevchenko