Re: [PATCH] i2c: omap: Improve error reporting for problems during .remove()

[Tony Lindgren <tony@atomide.com>]

* Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [230413 07:37]:
> Hello Tony,
> 
> On Thu, Apr 13, 2023 at 10:11:24AM +0300, Tony Lindgren wrote:
> > * Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [230413 07:07]:
> > > On Thu, Apr 13, 2023 at 09:39:15AM +0300, Tony Lindgren wrote:
> > > > Oh OK. Care to clarify a bit why we are not allowed to return errors
> > > > on remove though? Are we getting rid of the return value for remove?
> > > > Sorry if I'm not following the cunning plan here :)
> > > 
> > > Yes, that's the plan. If you look at the caller of the remove functions
> > > (before 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c):
> > > 
> > > static void platform_remove(struct device *_dev)
> > > {
> > >         struct platform_driver *drv = to_platform_driver(_dev->driver);
> > >         struct platform_device *dev = to_platform_device(_dev);
> > > 
> > >         if (drv->remove) {
> > >                 int ret = drv->remove(dev);
> > > 
> > >                 if (ret)
> > >                         dev_warn(_dev, "remove callback returned a non-zero value. This will be ignored.\n");
> > >         }
> > >         dev_pm_domain_detach(_dev, true);
> > > }
> > > 
> > > you see it's pointless to return an error value. But the prototype
> > > seduces driver authors to do it yielding to error that can easily
> > > prevented if .remove returns void. See also
> > > 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c for some background and details
> > > of the quest.
> > 
> > OK thanks. So maybe check the pm_runtime_get_sync() and on error do
> > pm_runtime_put_noidle(), or pm_runtime_resume_and_get(). Both ways
> > are fine for me, maybe you already figured it out.
> 
> Is this an Ack for my patch?

Yes looking at it again:

Reviewed-by: Tony Lindgren <tony@atomide.com>

Thanks,

Tony