linux-kernel - Re: [PATCH 2/4] mmc: host: sdhci-esdhc-imx: refactor the system PM logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFpectKosHEU7cm7uNCNwHZaT0XCSn674dGtu8Y+hmf_Pw@mail.gmail.com>
Date: Tue, 22 Oct 2024 10:28:49 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Bough Chen <haibo.chen@....com>
Cc: "adrian.hunter@...el.com" <adrian.hunter@...el.com>, 
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>, 
	"shawnguo@...nel.org" <shawnguo@...nel.org>, "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>, 
	"kernel@...gutronix.de" <kernel@...gutronix.de>, "festevam@...il.com" <festevam@...il.com>, dl-S32 <S32@....com>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] mmc: host: sdhci-esdhc-imx: refactor the system PM logic

On Fri, 18 Oct 2024 at 05:20, Bough Chen <haibo.chen@....com> wrote:
>
> > -----Original Message-----
> > From: Bough Chen
> > Sent: 2024年10月18日 9:23
> > To: Ulf Hansson <ulf.hansson@...aro.org>
> > Cc: adrian.hunter@...el.com; linux-mmc@...r.kernel.org; imx@...ts.linux.dev;
> > shawnguo@...nel.org; s.hauer@...gutronix.de; kernel@...gutronix.de;
> > festevam@...il.com; dl-S32 <S32@....com>;
> > linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org
> > Subject: RE: [PATCH 2/4] mmc: host: sdhci-esdhc-imx: refactor the system PM
> > logic
> >
> > > -----Original Message-----
> > > From: Ulf Hansson <ulf.hansson@...aro.org>
> > > Sent: 2024年10月17日 21:07
> > > To: Bough Chen <haibo.chen@....com>
> > > Cc: adrian.hunter@...el.com; linux-mmc@...r.kernel.org;
> > > imx@...ts.linux.dev; shawnguo@...nel.org; s.hauer@...gutronix.de;
> > > kernel@...gutronix.de; festevam@...il.com; dl-S32 <S32@....com>;
> > > linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org
> > > Subject: Re: [PATCH 2/4] mmc: host: sdhci-esdhc-imx: refactor the
> > > system PM logic
> > >
> > > On Mon, 14 Oct 2024 at 08:00, <haibo.chen@....com> wrote:
> > > >
> > > > From: Haibo Chen <haibo.chen@....com>
> > > >
> > > > Current suspend/resume logic has one issue. in suspend, will config
> > > > register when call sdhci_suspend_host(), but at this time, can't
> > > > guarantee host in runtime resume state. if not, the per clock is
> > > > gate off, access register will hung.
> > > >
> > > > Now use pm_runtime_force_suspend/resume() in
> > NOIRQ_SYSTEM_SLEEP_PM,
> > > > add in NOIRQ stage can cover SDIO wakeup feature, because in
> > > > interrupt handler, there is register access, need the per clock on.
> > > >
> > > > In sdhci_esdhc_suspend/sdhci_esdhc_resume, remove
> > > > sdhci_suspend_host() and sdhci_resume_host(), all are handled in
> > > > runtime PM callbacks except the wakeup irq setting.
> > > >
> > > > Remove pinctrl_pm_select_default_state() in sdhci_esdhc_resume,
> > > > because
> > > > pm_runtime_force_resume() already config the pinctrl state according
> > > > to ios timing, and here config the default pinctrl state again is
> > > > wrong for
> > > > SDIO3.0 device if it keep power in suspend.
> > >
> > > I had a look at the code - and yes, there are certainly several
> > > problems with PM support in this driver.
> > >
> > > >
> > > > Signed-off-by: Haibo Chen <haibo.chen@....com>
> > > > ---
> > > >  drivers/mmc/host/sdhci-esdhc-imx.c | 39
> > > > +++++++++++++++---------------
> > > >  1 file changed, 19 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
> > > > b/drivers/mmc/host/sdhci-esdhc-imx.c
> > > > index c7582ad45123..18febfeb60cf 100644
> > > > --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> > > > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> > > > @@ -1871,11 +1871,13 @@ static int sdhci_esdhc_suspend(struct device
> > > *dev)
> > > >         struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
> > > >         int ret;
> > > >
> > > > -       if (host->mmc->caps2 & MMC_CAP2_CQE) {
> > > > -               ret = cqhci_suspend(host->mmc);
> > > > -               if (ret)
> > > > -                       return ret;
> > > > -       }
> > > > +       /*
> > > > +        * Switch to runtime resume for two reasons:
> > > > +        * 1, there is register access, so need to make sure gate on ipg
> > clock.
> > >
> > > You are right that we need to call pm_runtime_get_sync() for this reason.
> > >
> > > However, the real question is rather; Under what circumstances do we
> > > really need to make a register access beyond this point?
> > >
> > > If the device is already runtime suspended, I am sure we could just
> > > leave it in that state without having to touch any of its registers.
> > >
> > > As I understand it, there are mainly two reasons why the device may be
> > > runtime resumed at this point:
> > > *) The runtime PM usage count has been bumped in
> > > sdhci_enable_sdio_irq(), since the SDIO irqs are enabled and it's
> > > likely that we will configure them for system wakeup too.
> > > *) The device has been used, but nothing really prevents it from being
> > > put into a low power state via the ->runtime_suspend() callback.
> > >
> > > > +        * 2, make sure the pm_runtime_force_suspend() in NOIRQ
> > > > + stage
> > > really
> > > > +        *    invoke its ->runtime_suspend callback.
> > > > +        */
> > >
> > > Rather than using the *noirq-callbacks, we should be able to call
> > > pm_runtime_force_suspend() from sdhci_esdhc_suspend(). And vice versa
> > > for sdhci_esdhc_resume().
> > >
> > > Although, according to my earlier comment above, we also need to take
> > > into account the SDIO irq. If it's being enabled for system wakeup, we
> > > must not put the controller into low power mode by calling
> > > pm_runtime_force_suspend(), otherwise we will not be able to deliver the
> > wakeup, right?
> >
> > Thanks for your careful review!
> > Yes, I agree.
>
> Hi Ulf,
>
> Sorry, I maybe give the wrong answer.
>
> I double check the IP, usdhc can support sdio irq wakeup even when usdhc clock gate off.

Okay, so there is some out-band logic that can manage the SDIO irq,
even when the controller has been runtime suspended?

In these cases, we use dev_pm_set_dedicated_wake_irq* to manage that
wake-irq. There are other mmc host drivers that implement support for
this too.

If you are referring to solely clock gating, that is not going to
work. A runtime suspended controller is not supposed to deliver
in-band irqs.

> So to save power, need to call pm_runtime_force_suspend() to gate off the clock when enable sdio irq for system wakeup.
> This is the main reason I involve pm_runtime_force_suspend in noirq stage, because in sdhci_irq, there is register access, need gate on clock.

In summary, to support the out-band irq as a wakeup for runtime and
system suspend, dev_pm_set_dedicated_wake_irq* should be used.

To move things forward, I suggest you start simple and add support for
the out-band irq as a step on top.

[...]

Kind regards
Uffe