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-rBigLPfJ6u5LQZ4FwMMm_h3b5fQiRYFkwNjFHm4cDCN1VRw@mail.gmail.com>
Date:   Wed, 30 Aug 2023 16:13:58 -0400
From:   Sven van Ashbrook <svenva@...omium.org>
To:     Ben Chuang <benchuanggli@...il.com>
Cc:     "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        skardach@...gle.com, 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,
        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

On Tue, Aug 29, 2023 at 10:27 PM Ben Chuang <benchuanggli@...il.com> wrote:
>
> >
> > - if /sys/devices/.../power/control is "on", then:
> >   <snip>
> >
> In this cas, after gl9763e_resume(), it is LPM disabled.
> Is there no chance for gl9763e to enter L1.x again when the system is idle?
>

AFAIK the only way to disable runtime_pm is to write:
  $ echo on > /sys/devices/.../power/control
where
  $ echo auto > /sys/devices/.../power/control
      means: runtime_pm is actively managing the device, device can be "active"
      or "suspended".
  $ echo on > /sys/devices/.../power/control
      means: runtime_pm is not managing the device, device is "active" only.

In the "auto" case, we know what should happen: LPM negotiation is enabled when
idle, disabled when active.

What should be the LPM negotiation state in the "on" case? We have to
make a choice:
a) LPM negotiation disabled: normal performance, high power consumption, OR
b) LPM negotiation  enabled: low    performance, low  power consumption

If userspace disables our device's runtime_pm by writing "on", it expects the
device to be always-on. It should then expect a higher power consumption.
It should then also expect a performance that is not-worse than the "auto" case.

So my suggestion would be to use (a), which is what this patch does.

Appreciate your thoughts.