On Mon, 21 Jun 2021 at 03:38, hieagle <chgokhl@xxxxxxxxx> wrote: > > Sorry, I don't receive the reply email in my gmail. > > Normally the mmc_host's power.disable_depth is large than zero, the > rpm_resume(mmc:0001) will not be called recursively for parent. This is > the most case. > > Although the mmc class device never calls pm_runtime_enable() directly, > there are still some cases as below to call pm_runtime_enable(), which > may cause it's power.disable_depth decremented to zero. > case1: device_resume_early->pm_runtime_enable > case2: device_resume->pm_runtime_enable Those calls to pm_runtime_enable() are in balance with previous calls to __pm_runtime_disable and pm_runtime_disable(), in __device_suspend() and __device_suspend_late(). In other words, the power.disable_depth is not being decremented to zero in any of those above path, I think. > > Anything that can go wrong will go wrong. Unfortunately we meet the case. > If you trigger to set the mmc_host's power.disable_depth value to zero > after mmc suspended, you can find the issue. > > In our platform the mmc device's parent list is as below: > mmc0:0001->mmc_host mmc0->fa630000.mmc->soc. > The rpm_resume call trace is as below in our scenario: > > rpm_resume(mmc0:0001) > | > if (!parent && dev->parent) //true > if (!parent->power.disable_depth > && !parent->power.ignore_children) //true > rpm_resume(parent, 0) ---> rpm_resume(mmc_host, 0) > | | > | callback = RPM_GET_CALLBACK(mmc_host, ...) = NULL > | retval = rpm_callback(callback, mmc_host) = -ENOSYS > | | > | return retval = -ENOSYS > if (retval) goto out; //skip rpm_callback() > return retval = -ENOSYS > > The scenario is rare, but anything that can go wrong will go wrong. > The patch can enhance the code to avoid this scenario. Well, I am still not convinced as I don't see how the power.disable_depth can ever reach zero. If you could provide a stack-trace of when power.disable_depth reaches zero, that would be helpful. [...] Kind regards Uffe
