Re: [PATCH 2/2] thermal: rcar_thermal: use pm_runtime_put_sync()

[Rafael J. Wysocki]

On Tuesday, November 10, 2015 02:00:38 PM Ulf Hansson wrote:
> +Rafael, Alan
> 
> On 10 November 2015 at 11:10, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > Hi Ulf,
> >

[cut]

> >>
> >> The problem is that the runtime PM status of the device isn't
> >> correctly updated at ->remove(). The effect is that the the
> >> pm_runtime_get_sync() in ->probe() at re-bind will *not* trigger the
> >> ->runtime_resume() callbacks to be invoked, as the runtime PM core
> >> believes the device is already runtime resumed.
> >
> > So that's where it should be fixed?
> 
> That would be a more generic approach, although I am not sure how the
> driver/PM core should be able to take the correct decision in this
> phase. Devices may be runtime PM managed also without a driver bound.
> 
> Perhaps when __device_release_driver() finds a bounded driver for the
> device, it could after all actions been performed to unbind the
> driver, check if runtime PM is enabled. If it isn't, it could set the
> runtime PM status to suspended!?
> 
> I have no idea if that would introduce other issues as it would kind
> of force the runtime PM status of the device to suspend, without
> actually knowing if it's the correct thing to do.

IMO, that needs to depend on the bus type.  If the bus type has a way
to manage PM for devices without drivers, it should be allowed to do so.

Of course, the platform bus type is somewhat special in that respect,
but it looks like we simply need some sort of a convention in there too
(the expectations should be the same for everybody).

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/