* Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> [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@xxxxxxxxxxxxxx> [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@xxxxxxxxxxx>
Thanks,
Tony
