Hi, On Tue, Nov 10, 2015 at 02:00:38PM +0100, Ulf Hansson wrote: > +Rafael, Alan > > On 10 November 2015 at 11:10, Geert Uytterhoeven <[email protected]> wrote: > > Hi Ulf, > > > > On Tue, Nov 10, 2015 at 10:57 AM, Ulf Hansson <[email protected]> > > wrote: > >> On 10 November 2015 at 09:18, Geert Uytterhoeven <[email protected]> > >> wrote: > >>> On Tue, Nov 10, 2015 at 3:12 AM, Kuninori Morimoto > >>> <[email protected]> wrote: > >>>> From: Kuninori Morimoto <[email protected]> > >>>> > >>>> It is using pm_runtime_get_sync() on probe(). Let's use > >>>> pm_runtime_put_sync() instead of pm_runtime_put(). Otherwise thermal > >>>> sensor doesn't work after unbind/re-bind > >>>> > >>>> Signed-off-by: Kuninori Morimoto <[email protected]> > >>>> --- > >>>> drivers/thermal/rcar_thermal.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/thermal/rcar_thermal.c > >>>> b/drivers/thermal/rcar_thermal.c > >>>> index 13d01ed..f7cf2d7 100644 > >>>> --- a/drivers/thermal/rcar_thermal.c > >>>> +++ b/drivers/thermal/rcar_thermal.c > >>>> @@ -373,7 +373,7 @@ static int rcar_thermal_remove(struct > >>>> platform_device *pdev) > >>>> thermal_zone_device_unregister(priv->zone); > >>>> } > >>>> > >>>> - pm_runtime_put(dev); > >>>> + pm_runtime_put_sync(dev); > >>>> pm_runtime_disable(dev); > >> > >> For the reasons explained by Geert, this is to me also a "workaround". > >> > >> I would replace pm_runtime_put() and pm_runtime_disable() with a call > >> to pm_runtime_force_suspend(). > >> > >> In that way, you will make sure you device get runtime suspended > >> (clock domain will gate the clock). Additionally, the runtime PM > >> status will properly reflect the status of the device. > > > > That still sounds like a workaround to me, which we have to apply to all > > drivers relying on Runtime PM? > > Definitely not all drivers, but those that runs pm_runtime_get_sync() > during ->probe() and expects the ->runtime_resume() callback to always > be invoked because of that. I guess we need to check upon which > drivers that may suffer from this. > > I wouldn't be surprised if at least a subset of those cases we find, > are poorly designed from PM point of view and won't even probe > successfully unless CONFIG_PM is set. Whatever that means...
Yeah, if it is the case this is a bug in runtime pm core, I would prefer this to be properly fixed, and not only this driver benefits of it. Rafael? Any thoughts? BR, Eduardo Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
