Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210320045720.11872-1-chgokhl@gmail.com> <CAPDyKFqXtKPngfnQZXXaF=rvqw0=nWzDc7P++QxNHPwGHHSxUA@mail.gmail.com>
 <CAMjpFAUTsei-PWLDdM+_78qXTo=QFdw-Wbgo9QA2Jnss+i4yRA@mail.gmail.com>
In-Reply-To: <CAMjpFAUTsei-PWLDdM+_78qXTo=QFdw-Wbgo9QA2Jnss+i4yRA@mail.gmail.com>
From:   Ulf Hansson <ulf.hansson@linaro.org>
Date:   Mon, 21 Jun 2021 11:20:36 +0200
Message-ID: <CAPDyKFqUhx8SmpXj=kmxzEKLWt4RU8rTxiiQgAXWX=fzmL=J0Q@mail.gmail.com>
Subject: Re: [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no_callbacks
To:     chgokhl@163.com
Cc:     linux-mmc <linux-mmc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        kehuanlin@fishsemi.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, 21 Jun 2021 at 03:38, hieagle <chgokhl@gmail.com> 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