linux-kernel - Re: [PATCH] mmc: sdhci-pci-gli: Disable LPM during initialization

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]

Date:   Fri, 10 Nov 2023 11:58:24 -0500
From:   Sven van Ashbrook <svenva@...omium.org>
To:     Kornel Dulęba <korneld@...omium.org>,
        Rafael J Wysocki <rafael@...nel.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Jason Lai <jasonlai.genesyslogic@...il.com>,
        Victor Shih <victor.shih@...esyslogic.com.tw>,
        Ben Chuang <ben.chuang@...esyslogic.com.tw>,
        Stanisław Kardach <skardach@...gle.com>,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH] mmc: sdhci-pci-gli: Disable LPM during initialization

There's something happening in this driver that doesn't
make much sense to me.

According to the pm runtime docs [1] the initial runtime pm
status of all devices is 'suspended'. Which I presume, means:
if the driver doesn't use any of the pm_runtime_*() functions
to tell the core "actually, I am active after probe", then the
device remains suspended until explicitly going active, at which
point the runtime_resume() callback is invoked.

That's the theory. In practice, what do I see on a device
containing this bridge?
Intel SoC <-> PCIe bus <-> gl9763e bridge <-> eMMC bus <-> eMMC drive

at probe() (does not exist in this driver so I stubbed it):
[ 0.601542] runtime pm is enabled = 1 (disable_depth == 0)
[ 0.601552] runtime pm is active = 2 (usage_count)

at probe_slot():
[ 0.602024] runtime pm is enabled = 1
[ 0.602027] runtime pm is active = 2

At add_host():
[ 0.602804] runtime pm is enabled = 1
[ 0.602809] runtime pm is active = 3

It looks like:
- nowhere does the gl9763e driver inform runtime pm it's active
- the device is active in probe(), probe_slot() and add_host()
- the runtime_resume() callback did not get called before
probe(), probe_slot(), or add_host().

Why is the runtime_resume() callback not invoked?
Does the driver have a runtime_pm misconfiguration issue here?

Perhaps Rafael could clarify?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/power/runtime_pm.rst?h=v6.6.1#n563