From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A25EC433E6 for ; Sat, 26 Dec 2020 15:27:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB44A20829 for ; Sat, 26 Dec 2020 15:27:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726230AbgLZP1b (ORCPT ); Sat, 26 Dec 2020 10:27:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726196AbgLZP1b (ORCPT ); Sat, 26 Dec 2020 10:27:31 -0500 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDE6EC0613C1; Sat, 26 Dec 2020 07:26:50 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id c133so5585099wme.4; Sat, 26 Dec 2020 07:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xIRdlgq1jjLTt5aUq57YZH004Efua6+AzHdbtC1vjHY=; b=P9kztiEr24T4l16RyEqA/W1xXXJ5wEhKXg8GPBu6E1B6wmYxYSXgZdczmd5SS7Hj6T zCwSaXeQ0z4fpETN6Ed0ee5CpglRVp6C2oUxSEFTOTCEcwUSafxiayDQ9gLNVBSUV3Hc Oae93nkcXWv7VldWP8g+uT3Ci6Vf0MLtUYATh3684wA0AXABD6ssiNC+rfwT7hcEEWjm A4XYXyZuti0vZ3H8ucWge5x7U8lAOaA4Ww8tbHnQLsB+r72cIIZ01v/GPm65HnirgfcG ZzDChtbPfXOrcqlV/pTEc2CqvMNWL1Hfel/yg2ECJ2sN7VvY3PhRy8SoNKdZzMHvLWOv PSFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xIRdlgq1jjLTt5aUq57YZH004Efua6+AzHdbtC1vjHY=; b=eX12yiGHQ9Kkj07CmclQXiWPKWHZuSuZL9oe4qhE9bpqFqlH7m86r8OjTFwEkcupiS 1ierRaVxTMidgbLMF3GE9kb3m5TLd+dKgD1siWAMEaQcy0qMRtIjvWybg634JSrdN/ar ONKTsXnDk074Wm01qIqKT0dBjaHwY46rgHgFNZsMl/810WkJ4i9s6M0pgLpxwIelStnl RkP9hhVmIHFRE0shYRCT+tdAiaotVO3xRQmyWC/BlOCuP4I++4SRQVOlLrpljAT/AvBM jc5Ft0Oy8uNOI3Psk/P08Gur84q9zRqAJ9ZFihwAYz4zKy8g+Rat20knMmOZrrBkcS8I UetA== X-Gm-Message-State: AOAM531F7wNJHoQzB/G//nC71NJO619nYmI+twedDRX3SECzaYnAGRdK gZ09KDYd1lgKGZMBUSCuwniG1kzXSwo= X-Google-Smtp-Source: ABdhPJz2smZ3Xe7YlFw9TmxjjLc/qldwG3Hnw+O5Ca7Q9lfBebaCrg9aTOICYJMC2SB5q/wEoThCmg== X-Received: by 2002:a1c:287:: with SMTP id 129mr12961595wmc.133.1608996409251; Sat, 26 Dec 2020 07:26:49 -0800 (PST) Received: from ?IPv6:2003:ea:8f06:5500:7d77:5a5b:aeb8:2b9f? (p200300ea8f0655007d775a5baeb82b9f.dip0.t-ipconnect.de. [2003:ea:8f06:5500:7d77:5a5b:aeb8:2b9f]) by smtp.googlemail.com with ESMTPSA id v20sm12423907wml.34.2020.12.26.07.26.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Dec 2020 07:26:48 -0800 (PST) Subject: Re: Time to re-enable Runtime PM per default for PCI devcies? To: "Rafael J. Wysocki" , Bjorn Helgaas Cc: "Rafael J. Wysocki" , Bjorn Helgaas , Mika Westerberg , Kai Heng Feng , Lukas Wunner , "linux-pci@vger.kernel.org" , Linux PM , Linux Kernel Mailing List References: <79940973-b631-90f9-dbc4-9579c6000816@gmail.com> <20201117163817.GA1397220@bjorn-Precision-5520> From: Heiner Kallweit Message-ID: Date: Sat, 26 Dec 2020 16:26:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On 17.11.2020 17:57, Rafael J. Wysocki wrote: > On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas 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) >>> 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. >