[PATCH 00/10] iio: prefer aligned_s64 timestamp (round 1)
Jonathan Cameron
jic23 at kernel.org
Mon Apr 21 04:17:52 PDT 2025
On Fri, 18 Apr 2025 18:05:42 -0500
David Lechner <dlechner at baylibre.com> wrote:
> On 4/18/25 2:58 PM, David Lechner wrote:
> > While reviewing the recent conversion to iio_push_to_buffers_with_ts(),
> > I found it very time-consuming to check the correctness of the buffers
> > passed to that function when they used an array with extra room at the
> > end for a timestamp. And we still managed find a few that were wrongly
> > sized or not properly aligned despite several efforts in the past to
> > audit these for correctness already.
> >
> > Even though these ones look to be correct, it will still be easier for
> > future readers of the code if we follow the pattern of using a struct
> > with the array and timestamp instead.
> >
> > For example, it is much easier to see that:
> >
> > struct {
> > __be32 data[3];
> > aligned_s64 timestamp;
> > } buffer;
> >
> After sending [1], I realized that some (perhaps many) of these would actually
> be a better candidate for the proposed IIO_DECLARE_BUFFER_WITH_TS macro rather
> that converting to the struct style as above.
>
> Case in point: if the driver using that struct allows reading only one channel,
> then the offset of the timestamp when doing iio_push_to_buffers_with_ts() would
> be 8 bytes, not 16, so the struct would not always be the correct layout.
>
> As long as the driver doesn't access the timestamp member of the struct, it
> doesn't really matter, but this could be a bit misleading to anyone who might
> unknowing try to use it in the future.
Agreed.
These timestamp inserting functions have always been a bit weird. I kind
of regret not just leaving it as a per driver thing to do, but that ship
long sailed. I definitely want to keep the layout apparent in the drivers
though so this approach only applied to 1 of the ones in this series.
Jonathan
>
> [1]: https://lore.kernel.org/linux-iio/20250418-iio-introduce-iio_declare_buffer_with_ts-v1-0-ee0c62a33a0f@baylibre.com/
More information about the linux-arm-kernel
mailing list