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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fc7ac047-e604-4a1a-a850-de1d44189565@intel.com>
Date:   Tue, 14 Nov 2023 12:26:24 +0200
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Sven van Ashbrook <svenva@...omium.org>,
        Kornel Dulęba <korneld@...omium.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        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, Rafael J Wysocki <rafael@...nel.org>
Subject: Re: [PATCH] mmc: sdhci-pci-gli: Disable LPM during initialization

On 10/11/23 18:58, Sven van Ashbrook wrote:
> 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

PCI subsystem does it in pci_pm_init()

> - 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?

Most drivers expect the device to be active at probe().  How it
gets that way is up to the bus.  Note, the driver may call 
pm_runtime_set_active() but that doesn't call runtime_resume().

> Does the driver have a runtime_pm misconfiguration issue here?

No

> 
> 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