linux-kernel - Re: Time to re-enable Runtime PM per default for PCI devcies?

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: <02216a23-067a-03aa-4663-b8f64e8ec78e@gmail.com>
Date:   Tue, 29 Dec 2020 22:11:59 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Bjorn Helgaas <helgaas@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Lukas Wunner <lukas@...ner.de>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Time to re-enable Runtime PM per default for PCI devcies?

On 29.12.2020 12:56, Kai-Heng Feng wrote:
> On Sat, Dec 26, 2020 at 11:26 PM Heiner Kallweit <hkallweit1@...il.com> wrote:
>>
>> On 17.11.2020 17:57, Rafael J. Wysocki wrote:
>>> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas <helgaas@...nel.org> wrote:
>>>>
>>>> [+to Rafael, author of the commit you mentioned,
>>>> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
>>>>
>>>> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
>>>>> More than 10 yrs ago Runtime PM was disabled per default by bb910a7040
>>>>> ("PCI/PM Runtime: Make runtime PM of PCI devices inactive by default").
>>>>>
>>>>> Reason given: "avoid breakage on systems where ACPI-based wake-up is
>>>>> known to fail for some devices"
>>>>> Unfortunately the commit message doesn't mention any affected  devices
>>>>> or systems.
>>>
>>> Even if it did that, it wouldn't have been a full list almost for sure.
>>>
>>> We had received multiple problem reports related to that, most likely
>>> because the ACPI PM in BIOSes at that time was tailored for
>>> system-wide PM transitions only.
>>>
>>
>> To follow up on this discussion:
>> We could call pm_runtime_forbid() conditionally, e.g. with the following
>> condition. This would enable runtime pm per default for all non-ACPI
>> systems, and it uses the BIOS date as an indicator for a hopefully
>> not that broken ACPI implementation. However I could understand the
>> argument that this looks a little hacky ..
>>
>> if (IS_ENABLED(CONFIG_ACPI) && dmi_get_bios_year() <= 2016)
> 
> dmi_get_bios_year() may not be a good indicator. Last time I used it
> caused regression, because the value changed after BIOS update.
> For example, my MacBook Pro is manufactured in 2011, but
> dmi_get_bios_year() returns 2018 with latest BIOS.
> 
Right, it's a weak indicator, and I'm aware of it. My thought is:
A massively broken ACPI implementation would have been fixed over
time if there are years between manufacturing date and last BIOS
update. Of course this doesn't have to be true ..

I just had a look at the ACPI spec and maybe we could use the ACPI
version information (major.minor) in the FADT table. E.g. we could
enable runtime pm from version 6.0. That should be reasonable new.
I'm open for any other proposals ..
 
> Kai-Heng
> 
>>
>>
>>
>>>>> With Runtime PM disabled e.g. the PHY on network devices may remain
>>>>> powered up even with no cable plugged in, affecting battery lifetime
>>>>> on mobile devices. Currently we have to rely on the respective distro
>>>>> or user to enable Runtime PM via sysfs (echo auto > power/control).
>>>>> Some devices work around this restriction by calling pm_runtime_allow
>>>>> in their probe routine, even though that's not recommended by
>>>>> https://www.kernel.org/doc/Documentation/power/pci.txt
>>>>>
>>>>> Disabling Runtime PM per default seems to be a big hammer, a quirk
>>>>> for affected devices / systems may had been better. And we still
>>>>> have the option to disable Runtime PM for selected devices via sysfs.
>>>>>
>>>>> So, to cut a long story short: Wouldn't it be time to remove this
>>>>> restriction?
>>>>
>>>> I don't know the history of this, but maybe Rafael or the others can
>>>> shed some light on it.
>>>
>>> The systems that had those problems 10 years ago would still have
>>> them, but I expect there to be more systems where runtime PM can be
>>> enabled by default for PCI devices without issues.
>>>
>>