linux-kernel - Re: [PATCH v2] mmc: sdhci-pci-gli: fix LPM negotiation so x86/S0ix SoCs can suspend

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: <CAG-rBig+koxDf3TuC-0p=tcBY_2WM1sPCvRDtjRmR7AnikrN-A@mail.gmail.com>
Date:   Mon, 28 Aug 2023 18:51:03 -0400
From:   Sven van Ashbrook <svenva@...omium.org>
To:     Ben Chuang <benchuanggli@...il.com>
Cc:     adrian.hunter@...el.com, SeanHY.chen@...esyslogic.com.tw,
        ben.chuang@...esyslogic.com.tw, greg.tu@...esyslogic.com.tw,
        jason.lai@...esyslogic.com.tw, jasonlai.genesyslogic@...il.com,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
        reniuschengl@...il.com, skardach@...gle.com,
        stable@...r.kernel.org, ulf.hansson@...aro.org,
        victor.shih@...esyslogic.com.tw, victorshihgli@...il.com
Subject: Re: [PATCH v2] mmc: sdhci-pci-gli: fix LPM negotiation so x86/S0ix
 SoCs can suspend

Hi Ben, thank you for reviewing this patch. See below.

On Mon, Aug 28, 2023 at 6:03 AM Ben Chuang <benchuanggli@...il.com> wrote:
>
> There is a situation for your reference.
> If `allow_runtime_pm' is set to false and the system resumes from suspend, GL9763E
> LPM negotiation will be always disabled on S0. GL9763E will stay L0 and never
> enter L1 because GL9763E LPM negotiation is disabled.
>
> This patch enables allow_runtime_pm. The simple flow is
> gl9763e_suspend() -> LPM enabled -> gl9763e_resume() -> LPM disabled -> (a)
> (a) -+--> idle -->  gl9763e_runtime_suspend() -> LPM enabled
>      |
>      +--> no idle -> gl9763e_runtime_resume() -> LPM disabled
>
> This patch disables allow_runtime_pm. The simple flow is
> gl9763e_suspend() -> LPM enabled -> gl9763e_resume() -> LPM disabled (no runtime_pm)
>
> Although that may not be the case with the current configuration, it's only a
> possibility.
>

Thanks so much for bringing this up. We have discussed internally and
as far as we know, the current patch will work correctly in all cases.
Could you verify our argument please?

The following assumptions are key:

1. If CONFIG_PM is set, the runtime_pm framework is always present, i.e. there
cannot exist a kernel which has PM but lacks runtime_pm.
2. The pm_runtime framework always makes sure the device is runtime
active before
calling XXX_suspend, waking it up if need be. So when XXX_suspend gets called,
the device is always runtime active.
3. if CONFIG_PM is set, runtime_pm can only be disabled via
echo on > /sys/devices/.../power/control, and then the runtime_pm framework
always keeps the device in runtime active. In such case LPM negotiation is
always disabled.

Using these assumptions, we get:

Runtime_pm allowed:
—------------------
gl9763e_runtime_resume() -> LPM disabled -> gl9763e_suspend() -> LPM enabled
-> gl9763e_resume() -> LPM disabled -> (a)
(a) -+--> idle --> gl9763e_runtime_suspend() -> LPM enabled
|
+--> no idle -> nothing - already runtime active -> LPM disabled

Runtime_pm not allowed:
—----------------------
gl9763e_runtime_resume() always called -> LPM always disabled
gl9763e_suspend() -> LPM enabled -> gl9763e_resume() -> LPM disabled

In all above cases the LPM negotiation flag is correct.

> >
> > sdhci doesn't know anything about the bus.  It is independent
> > of PCI, so I can't see how it would make any difference.
> > One of the people cc'ed might know more.  Jason Lai (cc'ed)
> > added it for runtime PM.
> >
>
> As far as I know, when disabling LPM negotiation, the GL9763E will stop entering
> L1. It doesn't other side effect. Does Jason.Lai and Victor.Shih have any comments
> or suggestions?

Sounds like everyone assumes that you can freely change LPM
negotiation on the PCIe
bus after the cqhci_suspend() and sdhci_suspend_host() calls, so we will assume
that too.