Re: [PATCH v2 4/4] iio: humidity: drop hid_sensor_remove_trigger() using devm API

[Andy Shevchenko]

On Thu, Apr 30, 2026 at 10:21 PM Sanjay Chitroda
<sanjayembeddedse@xxxxxxxxx> wrote:
> On 30 April 2026 1:03:56 am IST, Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:
> >On Wed, Apr 29, 2026 at 11:29:18PM +0530, Sanjay Chitroda wrote:
> >
> >> Use devm_hid_sensor_setup_trigger() to automatically release resource

resources

> >> during fail, unbind or removal of driver using devres framework.

failure

> >>
> >> This simplify the setup, remove goto, avoid manual resource cleanup in

simplifies
removes
and avoids

OR

"This is done in a way to simplify..."

> >> teardown path.

...

> >> +    ret = devm_hid_sensor_setup_trigger(&indio_dev->dev, indio_dev, name,
> >> +                                        &humid_st->common_attributes);
> >
> >I believe the first parameter is utterly wrong here.
> >Or other way around, same issue but in the previous patch.
> >
> Thank you Andy for the review comment.
>
> It looks in same humidity probe of hid sensor with devm API two device pointer are used &pdev->dev and &indio_dev->dev; ideally all devm should have same parent device for devres resource framework and over here preferable and consistent device should be &pdev->dev;
>
> I would first update existing devm_* API to have consistent device and on top of that will use same device in devm conversation.
>
> While for gyro change device is consistent as &pdev->dev across all devm API.

The idea is that you have to go deeply understanding the object
lifetimes for the cases of different device instances along with
userspace communication channels (all possible ABIs the driver uses).
With only that the proper parameter may be chosen or even confirmed
that device managed resources must not be used. Yeah, this is one of
the downsides of devm_*() APIs.

-- 
With Best Regards,
Andy Shevchenko