On Sun, 15 Dec 2024 23:18:14 +0200 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Sun, Dec 15, 2024 at 06:28:51PM +0000, Jonathan Cameron wrote: > > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > > > > 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@xxxxxxxxxxxxxxx> > > 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 >
