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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 D2A5BC64E75 for ; Tue, 17 Nov 2020 16:57:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9FE31246AD for ; Tue, 17 Nov 2020 16:57:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728211AbgKQQ5k (ORCPT ); Tue, 17 Nov 2020 11:57:40 -0500 Received: from mail-ot1-f49.google.com ([209.85.210.49]:35263 "EHLO mail-ot1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727070AbgKQQ5j (ORCPT ); Tue, 17 Nov 2020 11:57:39 -0500 Received: by mail-ot1-f49.google.com with SMTP id n11so20124324ota.2; Tue, 17 Nov 2020 08:57:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7NLRFj8nHCygasEBHceubBbH3HeMeHr99Ml1bGtCW9o=; b=N5aNtxPcylGbM7jh2INd3qvaC2FQvMEQJUNcoC2Isb+oovuuhULsTKJfVzNgjVu1oa //h7p7GWTg9wbRmD8/8aCuycjv5fxjsnGkD2s3j2TyjRVLII3ZN0XKFbW8VHUznWgmT2 af1Q/U5SLoPQug9airMTihl8382tk5lfCGm9uiH60lDHgiWHA7AaY251NTHCBpw6K9Ul /KGo3Iqz3i8hYy0VW64EGqmY5MMDYFUdRXllWQiIC/pI40bARewAIqGe5dgoaDljvS1/ +D+GNtn8hrpRmcfLy6fVcwVn4BrF65wyUVyOvIlC5zuCCllheJyqhWXl2QTzEOZCsY56 BGbg== X-Gm-Message-State: AOAM531yvQqzPpk50ipQrIXigzHWbqhnqZX3g2YSSSL2MSxRE+xkts1V p93PizmXCLRHpdeJ5u5ZTD0eERFf26GXHs7cvdo= X-Google-Smtp-Source: ABdhPJzociPk59c3aEW92lx5PQkRb0ADhjgmmggbLMdVyRcJQxet3/KWpklyWaGp1kYUDAKDDMgxsfmnnXhX+JFoXo8= X-Received: by 2002:a9d:16f:: with SMTP id 102mr3851962otu.206.1605632258611; Tue, 17 Nov 2020 08:57:38 -0800 (PST) MIME-Version: 1.0 References: <79940973-b631-90f9-dbc4-9579c6000816@gmail.com> <20201117163817.GA1397220@bjorn-Precision-5520> In-Reply-To: <20201117163817.GA1397220@bjorn-Precision-5520> From: "Rafael J. Wysocki" Date: Tue, 17 Nov 2020 17:57:27 +0100 Message-ID: Subject: Re: Time to re-enable Runtime PM per default for PCI devcies? To: Bjorn Helgaas Cc: Heiner Kallweit , "Rafael J. Wysocki" , Bjorn Helgaas , Mika Westerberg , Kai Heng Feng , Lukas Wunner , "linux-pci@vger.kernel.org" , Linux PM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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.