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

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 1 May 2026 21:25:35 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Thu, Apr 30, 2026 at 10:21 PM Sanjay Chitroda
> <sanjayembeddedse@gmail.com> wrote:
> > On 30 April 2026 1:03:56 am IST, Andy Shevchenko <andriy.shevchenko@intel.com> 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.
> 
FWIW it's always wrong from a design point of view to use iio_dev->dev
for devm.  It works but leaves us open to getting the ordering wrong
as some other stuff (including things you can't necessarily see explicitly
in a driver) will be using the parent device.

Jonathan