public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
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;
>  	}
> 


  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