| 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
| ||
|
Message-ID:
<DU0PR04MB9496E6ED8D3D6EB1FD26B450905C2@DU0PR04MB9496.eurprd04.prod.outlook.com>
Date: Thu, 7 Nov 2024 09:20:50 +0000
From: Bough Chen <haibo.chen@....com>
To: Ulf Hansson <ulf.hansson@...aro.org>, "adrian.hunter@...el.com"
<adrian.hunter@...el.com>
CC: "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
> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@...aro.org>
> Sent: 2024年10月22日 16:29
> 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 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?
Hi Ulf,
Sorry for the late reply.
Seems not out-band logic, refer to SD Host Controller Standard Specification Version 3.00, 2.2.13 Wakeup Control Register (Offset 02Bh), P45
Or refer to static bool sdhci_enable_irq_wakeups(struct sdhci_host *host) in sdhci.c
>
> 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.
In sdhci_irq(), it will check host->runtime_suspended, if in runtime suspend state, directly return. But for SDIO wakeup irq, here will meet irq storm, because no place to clear the interrupt status register.
This is why I involve noirq pm, force runtime resume before system handle sdio wakeup irq.
Or to support in-band SDIO wakeup, add some changes in common sdhic.c, just like following, which do you prefer? Or any thought?
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0b46b50aa28b..8928af3e62d3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3532,7 +3532,10 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
spin_lock(&host->lock);
if (host->runtime_suspended) {
+ disable_irq_nosync(host->irq);
+ host->wakeup_pending = true;
spin_unlock(&host->lock);
return IRQ_NONE;
}
@@ -3878,6 +3881,10 @@ int sdhci_runtime_resume_host(struct sdhci_host *host, int soft_reset)
spin_lock_irqsave(&host->lock, flags);
host->runtime_suspended = false;
+ if (host->wakeup_pending) {
+ host->wakeup_pending = false;
+ enable_irq(host->irq);
+ }
/* Enable SDIO IRQ */
if (sdio_irq_claimed(mmc))
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index e62f483ff3b8..ce6f750cc4dc 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -536,6 +536,7 @@ struct sdhci_host {
bool reinit_uhs; /* Force UHS-related re-initialization */
bool runtime_suspended; /* Host is runtime suspended */
+ bool wakeup_pending;
bool bus_on; /* Bus power prevents runtime suspend */
bool preset_enabled; /* Preset is enabled */
bool pending_reset; /* Cmd/data reset is pending
Best Regards
Haibo Chen
>
> > 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
Powered by blists - more mailing lists