Re: [PATCH 02/10] iio: gyro: hid-sensor-gyro-3d: use local struct device

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 20 Jul 2026 22:35:11 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Mon, Jul 20, 2026 at 10:20:28PM +0530, Sanjay Chitroda wrote:
> > On 20 July 2026 5:24:33 pm IST, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:  
> > >On Mon, Jul 20, 2026 at 03:10:14PM +0530, Sanjay Chitroda via B4 Relay wrote:  
> 
> ...
> 
> > >> -		dev_err(&pdev->dev, "failed to setup common attributes\n");
> > >> +		dev_err(dev, "failed to setup common attributes\n");
> > >>  		return ret;  
> > >
> > >Nope, First one (to eliminate a lot of churn) should be to convert this and
> > >similar to use
> > >
> > >		return dev_err_probe(...);  
> > 
> > Thank you for your input.
> > 
> > I'm planning to have a incremental series: first introduce a local "dev"
> > pointer, then convert the resource management to "devm_*", and finally
> > replace the remaining error reporting with "dev_err_probe()".
> > 
> > This keeps each series focused and avoids introducing intermediate patterns such as:
> > 
> >    ret = dev_err_probe(dev, ret, ...);
> >    goto error;
> > 
> > Once the cleanup paths are removed, those sites naturally become:
> > 
> >    return dev_err_probe(dev, ret, ...);
> > 
> > Does this approach sound reasonable?  
> 
> 
> No. First you should drop the dead code for sure (see above).
> Second, try to convert to dev_err_probe() as many drivers as you can without an
> intermediate change. If the driver requires an intermediate thing like the above
> it means it requires bigger refactoring. So, you should not have intermediate
> churn. With your current approach there are drivers that will have it, and for
> them you need to have different strategy (see my proposal in the above lines).

Note it is fine to bring in struct device *dev = ... as part of any
other cleanup change where it shortens things. 

Once you have done the more significant changes, chase them with a patch
in the same series to make use of dev in any remaining places.

The trick is to do all cleanup that is trampling on same lines in one
series so things like leaving a few cases to sweep up at the end in
a trivial patch look sensible.   Give you are working on a lot of
drivers, perhaps to keep things manageable you should clean up one or
two completely in a series then follow up with additional series to make
similar changes in the rest.

Jonathan


>