On Wed, 24 Jun 2026 14:18:17 +0300
Andy Shevchenko [off-list ref] wrote:

On Wed, Jun 24, 2026 at 07:13:12AM +0530, Sanjay Chitroda wrote:

quoted

On 23 June 2026 4:00:27 pm IST, Andy Shevchenko [off-list ref] wrote:  

quoted

On Mon, Jun 22, 2026 at 10:59:56AM +0530, Sanjay Chitroda wrote:  

quoted

This series avoid a race condition in HID IIO drivers related to the
ordering between callback registration and device exposure.

Currently, several HID IIO drivers register the IIO device (making it
visible to userspace and other kernel consumers) before all required
callbacks and resources are fully initialized, or rely on devm-based
cleanup in a way that does not guarantee correct teardown ordering.
This creates a window where the device can be accessed while it is  

There is a difference between "this creates" and "this might create".
I believe Srinivas and others were asking for the proof. So, what path
in the code makes this happen or possible to happen?
 

iio_device_register() exposes the IIO device to user space, while
sensor_hub_register_callback() registers callbacks for buffered IIO(streaming
mode).

This might create window where from userspace buffer mode is enabled and
callbacks are not registered which would result into loss of samples until
callback registration completes, although no explicit failure. In teardown
path which can resulting in stale/no data.

This was discussed in the v1 thread and v2 was posted based on discussion and
agreement:
 https://lore.kernel.org/all/3FED088A-651B-4E8B-840B-1B92CB4DF6F4@gmail.com/ (local)
  

quoted

quoted

not fully initialized or is being torn down, potentially leading to
sample drop or stale/no data.

To handle this, the series ensures that:
  - All required callbacks and resources are set up before the device
    is registered with the IIO core
  - Resource cleanup is performed explicitly where ordering matters

PS: This is prepratory series to convert all HID IIO driver to devm.

Testing:
  - Compiled with W=1 for each patch in series

---
Changes in v2:
- Drop fixes tag and rectify commit message with reference to that  

You also dropped my tag. Why?
 

Thank you for the review and tag on v1.

While code changes are intact in v2, the rational and commit message were
updated substantially. Since commit message is as important as change which
will be permanent in history for future reference, I chose to drop the tag to
request a fresh review.  

Now it's clear, thanks.
This version with changed commit messages seems good to me.
Reviewed-by: Andy Shevchenko <redacted>

Applied. Thanks,

quoted

I shall highlight the same in change log. I'll make sure to note in future revision.  

Yes, please.

quoted

quoted

quoted

- Link to v1: https://patch.msgid.link/20260606-5-june-hid-iio-race-fixes-v1-0-27a848c5758f@gmail.com