On Tue, Dec 10, 2019 at 1:00 AM Mark Brown broonie@kernel.org wrote:
On Tue, Dec 10, 2019 at 12:52:30AM +0800, Chuhong Yuan wrote:
I have a question that what if CONFIG_PM is not defined? Since I have met runtime PM before in the patch a31eda65ba21 ("net: fec: fix clock count mis-match"). I learned there that in some cases CONFIG_PM is not defined so runtime PM cannot take effect. Therefore, undo operations should still exist in remove functions.
There's also the case where runtime PM is there and the device is active at suspend - it's not that there isn't a problem, it's that we can't unconditionally do a disable because we don't know if there was a matching enable. It'll need to be conditional on the runtime PM state.
How about adding a check like #ifndef CONFIG_PM? I use this in an old version of the mentioned patch. However, that is not accepted since it seems not symmetric with enable in the probe. But I don't find an explicit runtime PM call in the probe here so the revision pattern of ("net: fec: fix clock count mis-match") seems not applicable. So I think adding a check is acceptable here, at least it solves the problem.