Re: [PATCH v3 7/9] iio: humidity: hid-sensor-humidity: use common device for devres

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 10 May 2026 09:42:49 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Sat, May 09, 2026 at 03:40:38PM +0530, Sanjay Chitroda wrote:
> 
> > kmemdup() is used for memory that is logically tied to the HID
> > platform device, even though the driver binds into the IIO framework.
> > 
> > Using &indio_dev->dev for devres allocations works functionally, but it
> > results in two separate devres ownership trees—one for the HID
> > platform device (pdev) and another for the IIO device (indio_dev).
> > 
> > The devres framework is intended to have a single, well-defined parent
> > device. Since the memory originates from HID sensor probing and is not
> > IIO-specific, &pdev->dev is the correct and logical owner.
> > 
> > Switch to using the platform device for devm_kmemdup() so that all
> > resources are released deterministically and consistently.  
> 
> This patch sounds like a required fix and has to be placed in the beginning of
> the series along with the Fixes tag.

Hmm. I always find these hard to prove... 
Ultimately for a device for which no driver is ever bound I believe
the call to devres_release_all() in device_release() catches these.

That should I think happen when the last reference to the iio_dev->dev
is dropped (for the device we care about in the 'buggy' code).
Now that may well be at a different time to when it would happen on
the underlying bus device unbind.  However here we are talking about
an allocation so as long as we release it at somepoint and that's late
enough (which it will be either way) then it's not a bug - it just makes
the code harder to reason about.

Jonathan

p.s. I remember testing the releases on some other drivers years ago
     to figure out if they had an actual bug based on the pattern we have
     here. It 'works' but yuk.