public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: David Lechner <dlechner@baylibre.com>
Cc: "Jiri Kosina" <jikos@kernel.org>,
	"Jonathan Cameron" <jic23@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>,
	linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] iio: orientation: hid-sensor-rotation: add timestamp hack to not break userspace
Date: Mon, 2 Mar 2026 10:50:10 +0200	[thread overview]
Message-ID: <aaVPQsvz02S8GtsX@ashevche-desk.local> (raw)
In-Reply-To: <20260301-iio-fix-timestamp-alignment-v1-1-1a54980bfb90@baylibre.com>

On Sun, Mar 01, 2026 at 02:24:50PM -0600, David Lechner 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.

...

> +		/*
> +		 * HACK: There are two copies of the same timestamp in case of

Usually we use FIXME in such cases. HACK is something which goes with
"do not apply".

Does it mean it will stay forever?

> +		 * userspace depending on broken alignment from older kernels.
> +		 */
> +		aligned_s64 timestamp[2];

...

> +		/*
> +		 * HACK: IIO previously had an incorrect implementation of

Ditto.

> +		 * 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
> +		 * depended on this broken behavior, we put the timestamp in
> +		 * both the correct place and the old incorrect place.
> +		 */
> +		rot_state->scan.timestamp[0] = rot_state->timestamp;
> +		rot_state->scan.timestamp[1] = rot_state->timestamp;

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-03-02  8:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-01 20:24 [PATCH 0/4] iio: buffer: fix timestamp alignment (in rare case) David Lechner
2026-03-01 20:24 ` [PATCH 1/4] iio: orientation: hid-sensor-rotation: add timestamp hack to not break userspace David Lechner
2026-03-02  8:50   ` Andy Shevchenko [this message]
2026-03-02 15:18     ` David Lechner
2026-03-02 20:39       ` Jonathan Cameron
2026-03-01 20:24 ` [PATCH 2/4] iio: buffer: check return value of iio_compute_scan_bytes() David Lechner
2026-03-01 20:24 ` [PATCH 3/4] iio: buffer: cache largest scan element size David Lechner
2026-03-02 12:16   ` Nuno Sá
2026-03-02 15:35     ` David Lechner
2026-03-02 16:18       ` Nuno Sá
2026-03-02 20:47   ` Jonathan Cameron
2026-03-02 21:58     ` David Lechner
2026-03-01 20:24 ` [PATCH 4/4] iio: buffer: fix timestamp alignment when quaternion in scan David Lechner
2026-03-02  8:47   ` Andy Shevchenko
2026-03-02 15:39     ` David Lechner
2026-03-02 16:03       ` Andy Shevchenko
2026-03-02 12:04   ` Nuno Sá
2026-03-02 15:42     ` David Lechner
2026-03-02 20:49       ` 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=aaVPQsvz02S8GtsX@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.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