From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Jiri Kosina" <jikos@kernel.org>,
"Srinivas Pandruvada" <srinivas.pandruvada@linux.intel.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Lars Möllendorf" <lars.moellendorf@plating.de>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Lixu Zhang" <lixu.zhang@intel.com>,
"Francesco Lavra" <flavra@baylibre.com>,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] iio: orientation: hid-sensor-rotation: add timestamp hack to not break userspace
Date: Sat, 14 Mar 2026 12:18:38 +0000 [thread overview]
Message-ID: <20260314121838.620a4b4c@jic23-huawei> (raw)
In-Reply-To: <20260307-iio-fix-timestamp-alignment-v2-1-d1d48fbadbbf@baylibre.com>
On Sat, 07 Mar 2026 19:44:09 -0600
David Lechner <dlechner@baylibre.com> wrote:
> Add a hack to push two timestamps in the hid-sensor-rotation scan data
> to avoid breaking userspace applications that depend on the timestamp
> being at the incorrect location in the scan data due to unintentional
> misalignment in older kernels.
>
> When this driver was written, the timestamp was in the correct location
> because of the way iio_compute_scan_bytes() was implemented at the time.
> (Samples were 24 bytes each.) Then commit 883f61653069 ("iio: buffer:
> align the size of scan bytes to size of the largest element") changed
> the computed scan_bytes to be a different size (32 bytes), which caused
> iio_push_to_buffers_with_timestamp() to place the timestamp at an
> incorrect offset.
>
> There have been long periods of time (6 years each) where the timestamp
> was in either location, so to not break either case, we open-code the
> timestamps to be pushed to both locations in the scan data.
>
> Reported-by: Jonathan Cameron <jic23@kernel.org>
> Closes: https://lore.kernel.org/linux-iio/20260215162351.79f40b32@jic23-huawei/
> Fixes: 883f61653069 ("iio: buffer: align the size of scan bytes to size of the largest element")
> Signed-off-by: David Lechner <dlechner@baylibre.com>
As suggested, I've applied this one to fixes-togreg and the rest will have
to wait for now. Interestingly this cycle has more fixes coming through
than any I remember! Hence I've sent a 2nd fixes pull and this will
be queued up for the 3rd in a week or so. It's possible the rest
might have to wait for next cycle though given round trip times etc.
Let's see.
Thanks for sorting this out and for the test scripts etc!
Jonathan
> ---
>
> v2 changes:
> - Rebased on fix that also touches the scan struct.
> - Improved comments.
>
> I found that I could emulate this thanks to /dev/uhid. And thanks to AI
> code generators, I was able to reasonably quickly make a script that
> worked for emulating "HID-SENSOR-20008a". See v1 message for test script
> source code.
>
> [v1]: https://lore.kernel.org/linux-iio/20260301-iio-fix-timestamp-alignment-v1-1-1a54980bfb90@baylibre.com/
>
> I set up the buffer like this:
>
> cd /sys/bus/iio/devices/iio:device1/buffer0
> echo 1 > in_rot_quaternion_en
> echo 1 > in_timestamp_en
> echo 1 > enable
>
> Before this series is applied, we can see that the timestamp (group of 8
> ending in "98 18") is at offset of 24 in the 32-byte data.
>
> hd /dev/iio\:device1
>
> 00000000 6a 18 00 00 ac f3 ff ff 83 2d 00 00 02 d3 ff ff |j........-......|
> 00000010 00 00 00 00 00 00 00 00 5a 17 a0 2a 73 cb 98 18 |........Z..*s...|
>
> 00000020 ad 17 00 00 6a f4 ff ff 35 2b 00 00 ca d0 ff ff |....j...5+......|
> 00000030 00 00 00 00 00 00 00 00 2a a6 bb 30 73 cb 98 18 |........*..0s...|
>
> 00000040 92 1e 00 00 50 ec ff ff ea c1 ff ff 78 f0 ff ff |....P.......x...|
> 00000050 00 00 00 00 00 00 00 00 8f 3b a7 39 77 cb 98 18 |.........;.9w...|
>
> After the first patch, we can see that the timestamp is now repeated at
> both the correct and previous incorrect offsets (24 and 32). (Normally,
> the last 8 bytes would be all 00 for padding.)
>
> 00000000 dd e0 ff ff 0e e0 ff ff 75 07 00 00 90 3f 00 00 |........u....?..|
> 00000010 f4 38 82 d0 3a cc 98 18 f4 38 82 d0 3a cc 98 18 |.8..:....8..:...|
>
> 00000020 a0 e0 ff ff 1d e0 ff ff a0 0a 00 00 1c 3f 00 00 |.............?..|
> 00000030 3a 29 9f d6 3a cc 98 18 3a 29 9f d6 3a cc 98 18 |:)..:...:)..:...|
>
> 00000040 a9 e1 ff ff 1e 14 00 00 6c c1 ff ff 98 f2 ff ff |........l.......|
> 00000050 39 21 77 11 55 cc 98 18 39 21 77 11 55 cc 98 18 |9!w.U...9!w.U...|
> ---
> drivers/iio/orientation/hid-sensor-rotation.c | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/orientation/hid-sensor-rotation.c b/drivers/iio/orientation/hid-sensor-rotation.c
> index 6806481873be..5a5e6e4fbe34 100644
> --- a/drivers/iio/orientation/hid-sensor-rotation.c
> +++ b/drivers/iio/orientation/hid-sensor-rotation.c
> @@ -20,7 +20,12 @@ struct dev_rot_state {
> struct hid_sensor_hub_attribute_info quaternion;
> struct {
> IIO_DECLARE_QUATERNION(s32, sampled_vals);
> - aligned_s64 timestamp;
> + /*
> + * ABI regression avoidance: There are two copies of the same
> + * timestamp in case of userspace depending on broken alignment
> + * from older kernels.
> + */
> + aligned_s64 timestamp[2];
> } scan;
> int scale_pre_decml;
> int scale_post_decml;
> @@ -154,8 +159,19 @@ static int dev_rot_proc_event(struct hid_sensor_hub_device *hsdev,
> if (!rot_state->timestamp)
> rot_state->timestamp = iio_get_time_ns(indio_dev);
>
> - iio_push_to_buffers_with_timestamp(indio_dev, &rot_state->scan,
> - rot_state->timestamp);
> + /*
> + * ABI regression avoidance: IIO previously had an incorrect
> + * implementation of iio_push_to_buffers_with_timestamp() that
> + * put the timestamp in the last 8 bytes of the buffer, which
> + * was incorrect according to the IIO ABI. To avoid breaking
> + * userspace that may be depending on this broken behavior, we
> + * put the timestamp in both the correct place [0] and the old
> + * incorrect place [1].
> + */
> + rot_state->scan.timestamp[0] = rot_state->timestamp;
> + rot_state->scan.timestamp[1] = rot_state->timestamp;
> +
> + iio_push_to_buffers(indio_dev, &rot_state->scan);
>
> rot_state->timestamp = 0;
> }
>
next prev parent reply other threads:[~2026-03-14 12:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 1:44 [PATCH v2 0/5] iio: buffer: fix timestamp alignment (in rare case) David Lechner
2026-03-08 1:44 ` [PATCH v2 1/5] iio: orientation: hid-sensor-rotation: add timestamp hack to not break userspace David Lechner
2026-03-14 12:18 ` Jonathan Cameron [this message]
2026-03-08 1:44 ` [PATCH v2 2/5] iio: buffer: check return value of iio_compute_scan_bytes() David Lechner
2026-03-08 1:44 ` [PATCH v2 3/5] iio: buffer: cache timestamp offset in scan buffer David Lechner
2026-03-08 1:44 ` [PATCH v2 4/5] iio: buffer: ensure repeat alignment is a power of two David Lechner
2026-03-08 1:44 ` [PATCH v2 5/5] iio: buffer: fix timestamp alignment when quaternion in scan David Lechner
2026-03-09 14:15 ` [PATCH v2 0/5] iio: buffer: fix timestamp alignment (in rare case) Nuno Sá
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=20260314121838.620a4b4c@jic23-huawei \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=flavra@baylibre.com \
--cc=gregkh@linuxfoundation.org \
--cc=jikos@kernel.org \
--cc=lars.moellendorf@plating.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lixu.zhang@intel.com \
--cc=nuno.sa@analog.com \
--cc=srinivas.pandruvada@linux.intel.com \
/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