From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-iio@vger.kernel.org, David Lechner <dlechner@baylibre.com>,
Heiko Stuebner <heiko@sntech.de>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH 15/20] iio: buffer: Make timestamp s64 in iio_push_to_buffers_with_timestamp()
Date: Mon, 23 Dec 2024 12:44:55 +0000 [thread overview]
Message-ID: <20241223124449.2bc68b9d@jic23-huawei> (raw)
In-Reply-To: <Z19GLcY8m6ErkHk1@smile.fi.intel.com>
On Sun, 15 Dec 2024 23:12:13 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Sun, Dec 15, 2024 at 06:29:06PM +0000, Jonathan Cameron wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > This is a bit of a corner case for selecting between the in kernel types
> > and standard c integer types we tend to prefer for userspace interfaces.
>
> s/c/C/
>
> > The interface is entirely within the kernel but in many cases the data
> > ultimately ends up in userspace (via some time in a kfifo). On balance
> > the value passed is almost always an s64, so standardize on that.
> > Main reason to change this is that it has led to some inconsistency in
> > the storage type used. The majority use aligned_s64 rather than
> > int64_t __aligned(8) and this will ensure there is one obvious choice.
>
> ...
>
> > static inline int iio_push_to_buffers_with_timestamp(struct iio_dev *indio_dev,
> > - void *data, int64_t timestamp)
> > + void *data, s64 timestamp)
>
> Hmm... Is it the indentation used for other static inline definitions there?
> Otherwise I would fix it to follow standard pattern (use same column as the
> first argument).
Makes sense.
>
> ...
>
> > if (indio_dev->scan_timestamp) {
> > - size_t ts_offset = indio_dev->scan_bytes / sizeof(int64_t) - 1;
> > - ((int64_t *)data)[ts_offset] = timestamp;
> > + size_t ts_offset = indio_dev->scan_bytes / sizeof(s64) - 1;
>
> sizeof(timestamp) ?
I think not on this one. It's about the type of the cast on the next line more
than timestamp type. If timestamp were an s32 and we were writing it into
a 64 bit location then sizeof(timestamp) would be the wrong size but whereas
the proposal here would still work. If we were doing a memcpy rather than
a simple assignment the sizes would have to be the same and your suggestion
would make sense.
Could introduce a local variable to make this more obvious and provide a
parameter for the sizeof()
s64 *datas64 = (s64 *)data;
size_t ts_offset = indio-dev->scan_bytes / sizeof(*datas64) - 1;
datas64[ts_offset] = timestamp;
Do you think that is worth doing or just adding complexity we don't need?
I don't see it as much more readable, so think on balance sticking to original
proposal in this patch makes more sense.
Note this needed a rebase anyway as scan_timestamp is now private.
>
> > + ((s64 *)data)[ts_offset] = timestamp;
> > }
>
next prev parent reply other threads:[~2024-12-23 12:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-15 18:28 [PATCH 00/20] IIO: Tidying up timestamp alignment markings Jonathan Cameron
2024-12-15 18:28 ` [PATCH 01/20] iio: adc: ad7944: Fix sign and use aligned_s64 for timestamp Jonathan Cameron
2024-12-15 18:36 ` David Lechner
2024-12-15 18:28 ` [PATCH 02/20] io: adc: ina2xx-adc: " Jonathan Cameron
2025-01-30 15:40 ` Uwe Kleine-König
2025-01-30 16:10 ` Jonathan Cameron
2024-12-15 18:28 ` [PATCH 03/20] iio: temperature: tmp006: Use aligned_s64 instead of open coding alignment Jonathan Cameron
2024-12-15 18:28 ` [PATCH 04/20] iio: resolver: ad2s1210: " Jonathan Cameron
2024-12-15 18:28 ` [PATCH 05/20] iio: proximity: " Jonathan Cameron
2024-12-15 18:28 ` [PATCH 06/20] iio: pressure: " Jonathan Cameron
2024-12-16 7:52 ` Matti Vaittinen
2024-12-15 18:28 ` [PATCH 07/20] iio: magnetometer: " Jonathan Cameron
2024-12-15 18:28 ` [PATCH 08/20] iio: light: " Jonathan Cameron
2024-12-16 7:37 ` Matti Vaittinen
2024-12-15 18:29 ` [PATCH 09/20] iio: imu: " Jonathan Cameron
2024-12-15 18:29 ` [PATCH 10/20] iio: humidity: " Jonathan Cameron
2024-12-15 18:29 ` [PATCH 11/20] iio: gyro: " Jonathan Cameron
2024-12-15 18:29 ` [PATCH 12/20] iio: chemical: " Jonathan Cameron
2024-12-15 18:29 ` [PATCH 13/20] iio: adc: " Jonathan Cameron
2024-12-21 11:18 ` Marcelo Schmitt
2024-12-15 18:29 ` [PATCH 14/20] iio: accel: bma220: " Jonathan Cameron
2024-12-15 18:29 ` [PATCH 15/20] iio: buffer: Make timestamp s64 in iio_push_to_buffers_with_timestamp() Jonathan Cameron
2024-12-15 21:12 ` Andy Shevchenko
2024-12-23 12:44 ` Jonathan Cameron [this message]
2024-12-15 18:29 ` [PATCH 16/20] iio: adc: ti-lmp92064: Switch timestamp type from int64_t __aligned(8) to aligned_s64 Jonathan Cameron
2024-12-15 18:29 ` [PATCH 17/20] iio: chemical: scd4x: switch " Jonathan Cameron
2024-12-15 18:29 ` [PATCH 18/20] iio: imu: inv_icm42600: " Jonathan Cameron
2024-12-16 8:31 ` Jean-Baptiste Maneyrol
2024-12-15 18:29 ` [PATCH 19/20] iio: adc: mt6360: Correct marking of timestamp alignment Jonathan Cameron
2024-12-15 18:29 ` [PATCH 20/20] iio: adc: rockchip: correct alignment of timestamp Jonathan Cameron
2024-12-15 21:18 ` [PATCH 00/20] IIO: Tidying up timestamp alignment markings Andy Shevchenko
2024-12-23 12:32 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241223124449.2bc68b9d@jic23-huawei \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dlechner@baylibre.com \
--cc=heiko@sntech.de \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox