Received: by 10.223.185.116 with SMTP id b49csp431615wrg; Tue, 20 Feb 2018 01:43:58 -0800 (PST) X-Google-Smtp-Source: AH8x227aGHATh+cuEvH9laUj/7ZEnCITZobXe9s4+J1KbV1pjyJUjhzmfVmdTDjQ7io2S4LFjTsb X-Received: by 2002:a17:902:bd89:: with SMTP id q9-v6mr5577572pls.172.1519119838878; Tue, 20 Feb 2018 01:43:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519119838; cv=none; d=google.com; s=arc-20160816; b=q1lcKwjgEq/1SEt9vX6Cx+DJ2KJbkkv6SsFDdH2X/Vj8GmsQjeYPwOBzGwwATX6PLI i8/WPRn+d1EFSX46I2uXYW0Pt0Tk4+UnbO9ZrwB0J2J7mDhVwN2Nn+scYpb9a2+Iak+7 Qh0b6Sq3mgFDiA6BaqOYemDliLJaG/lQwaK3IVRq1zKCxI5nC1kjD18Po92Is1yoAU94 DRtSNLeM/CxyC6Hrgpj/JW4f/2CTOzHPHaFQNQ+z6xdSutx51waGuhDHod8uhOet2xvE psqEur1gMins6yn8/rskvR1ZDu8xwYTnUN1GDYknGJvDalgiF+CJLMZCK3w6yT4GKX3u /MCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=a5Qyhc7nISe+scd/Clp5VKRkrKEcE5Ih06GS/xra28s=; b=Obg31JihArgeDkqK/r3mof4/C8Q/PixQrYv10evNnDvH8xdNS6WzYI6nMUBg/hsz7F aLR3/8PrkygGsEL8FiMFlSstcYx60AuX3rSehoY/b5gt2uw9yVGuA3DK7/rQeQvnGon6 ZYsTG+BOK+7o6islTMFRYX2micVuQ17l0u2i6LVna19A+L5JU/yY/B4CiWoKj4p0Ab4y Qkx4vYAmsnnuOrKx5OtFo6A8JCA/m9ehh3pWZGj5UeLswE0FBk90S0PbambbYJxDOeIs 7VfgPgEkFf6CKRZsUf+tDE1pKf+RiQnKRgXPKl1lwiuC7Aas8DtY99bppgpw5vZQxpdp slYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=IMjRxtoE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d64si1009937pfa.40.2018.02.20.01.43.44; Tue, 20 Feb 2018 01:43:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=IMjRxtoE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751408AbeBTJmA (ORCPT + 99 others); Tue, 20 Feb 2018 04:42:00 -0500 Received: from mail-ot0-f193.google.com ([74.125.82.193]:43023 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751334AbeBTJlf (ORCPT ); Tue, 20 Feb 2018 04:41:35 -0500 Received: by mail-ot0-f193.google.com with SMTP id q12so10851972otg.10; Tue, 20 Feb 2018 01:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=a5Qyhc7nISe+scd/Clp5VKRkrKEcE5Ih06GS/xra28s=; b=IMjRxtoERvn69o6HNs9k5VMZiZvW0II39W2/uSZteOQKL5nFPQESihEH2yLo6p1r2n ZOcTmIY4673PcAGg+oScScmvKFFkTnZdURQtthVHcP681XXtiBYM+LFhgBjeHKeflV8Q aLvT7JkCk7mWQ0ojNrWHcULP5Hzb6CRB4S8OWUnBrG8GA5y86vcLPqzDMe3tyAUI2GJx KMJLzh0MrP/tJvvKt/T4Z8VGxetsN10H7L3KYZaIg8utIfg/MSE2Qrca/oAgFGKNpINP 2fjjHMJGXMzHwiUwe76rFy7eVVbgwXToEqjtK6W7mo0tBKUijAL5eRcY5HS6pHqWHvOX kPmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=a5Qyhc7nISe+scd/Clp5VKRkrKEcE5Ih06GS/xra28s=; b=Z6TcHtmGTBBL2csykqoB3mk4mREwwIJG+Cpb5RzGjut3crYpcmpP5pHR4LWQ7W0tv/ lkwY4d1WFumqN6vfXTdawpElqEaQRX9FZEiwHOfSC7qAwlqmM9Atf6DIrgGGtTHbPlyg oPDYMLhpSfcBHYoYM4BbHbSfiAWeD60+3dpyIaaNeIbTwnlDj0ciklEsQMBflj1+0wrk 135uAH7z8KMoixP49vl6hwENQY7bBFZ4ZLNnxb/gLEHJbTTsfA4GElt8VEKuJqm/PXjy MqNvElrUHjoRvpk6YvODRvr8E0MwzB+pgWgpciOjj9tkBqP4YxhadHJ16izApUhsgEZ3 7H1A== X-Gm-Message-State: APf1xPANbOfiy2Ml2hO88/x2cnPDATbkCXI39DxzJa4eekEGGllrsVFM VjngeokPFMG55fRryz0GPt/VYLnkFoHr1DkM+jY= X-Received: by 10.157.25.173 with SMTP id k42mr7614300otk.370.1519119694277; Tue, 20 Feb 2018 01:41:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.44.146 with HTTP; Tue, 20 Feb 2018 01:41:33 -0800 (PST) In-Reply-To: <151908204614.37696.12828004282495415825.stgit@bhelgaas-glaptop.roam.corp.google.com> References: <151908155159.37696.9710083237704994886.stgit@bhelgaas-glaptop.roam.corp.google.com> <151908204614.37696.12828004282495415825.stgit@bhelgaas-glaptop.roam.corp.google.com> From: "Rafael J. Wysocki" Date: Tue, 20 Feb 2018 10:41:33 +0100 X-Google-Sender-Auth: WWG-nr_XkjWQUjYIh0we7OnXwdU Message-ID: Subject: Re: [PATCH v1 2/2] PCI: Allow user to request power management of conventional and hotplug bridges To: Bjorn Helgaas Cc: Linux PCI , Valdis Kletnieks , Mathias Nyman , Linux PM , Mika Westerberg , "Rafael J. Wysocki" , Linux Kernel Mailing List , Lukas Wunner , Peter Wu , Qipeng Zha , Greg Kroah-Hartman , Andreas Noever , Dave Airlie , Qi Zheng Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 20, 2018 at 12:14 AM, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > Previously "pcie_port_pm=force" enabled power management of PCI bridges, > but only for PCIe ports (not conventional PCI bridges) and only for ports > that do not support hotplug. Those limitations are there because we're not > confident that all those configurations work, not because the spec requires > them. > > Change "pcie_port_pm=force" to enable power management of conventional PCI > bridges and hotplug bridges as well as PCIe ports. As with the previous > PCIe port-only behavior, this is not expected to work in all systems. > > Add a "pci=bridge_pm" parameter to reflect the increased scope. For > backward compatibility, retain "pcie_port_pm=force" as an undocumented > equivalent. > > Add "pci=no_bridge_pm" as an equivalent to "pcie_port_pm=off". This > disables power management for all PCI bridges, which is results in the same > behavior as before, since we always disabled power management of > conventional PCI bridges, and "pcie_port_pm=off" disabled it for PCIe > ports. > > Signed-off-by: Bjorn Helgaas Honestly, I wouldn't do that, at least not this way. Somebody might be using pcie_port_pm=force already, for example, and it works for them for PCIe, but the PCI-to-PCI part of the same system may not. IMO the behavior of pcie_port_pm= should be as is and I don't see what's wrong with it being documented. Of course, you can add pci=bridge_pm/no_bridge_pm to extend the scope, but for what reason really? Just to follow the letter of the spec? > --- > Documentation/admin-guide/kernel-parameters.txt | 8 ++++---- > drivers/pci/pci.c | 21 ++++++++++++--------- > 2 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 1d1d53f85ddd..4660105ec851 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -3117,6 +3117,10 @@ > pcie_scan_all Scan all possible PCIe devices. Otherwise we > only look for one device below a PCIe downstream > port. > + bridge_pm Enable runtime power management of all bridges, > + including conventional PCI bridges, PCIe ports, > + and hotplug bridges. > + no_bridge_pm Disable runtime power management of all bridges. > big_root_window Try to add a big 64bit memory window to the PCIe > root complex on AMD CPUs. Some GFX hardware > can resize a BAR to allow access to all VRAM. > @@ -3143,10 +3147,6 @@ > compat Treat PCIe ports as PCI-to-PCI bridges, disable the PCIe > ports driver. > > - pcie_port_pm= [PCIE] PCIe port power management handling: > - off Disable power management of all PCIe ports > - force Forcibly enable power management of all PCIe ports > - > pcie_pme= [PCIE,PM] Native PCIe PME signaling options: > nomsi Do not use MSI for native PCIe PME signaling (this makes > all PCIe root ports use INTx for all services). > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 75db77cf3f8f..2aa1ae9c4afa 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -111,10 +111,8 @@ unsigned int pcibios_max_latency = 255; > /* If set, the PCIe ARI capability will not be used. */ > static bool pcie_ari_disabled; > > -/* Disable bridge_d3 for all PCIe ports */ > -static bool pci_bridge_d3_disable; > -/* Force bridge_d3 for all PCIe ports */ > -static bool pci_bridge_d3_force; > +static bool pci_bridge_d3_disable; /* Disable D3 for all bridges */ > +static bool pci_bridge_d3_force; /* Enable D3 for all bridges */ > > static int __init pcie_port_pm_setup(char *str) > { > @@ -2260,6 +2258,12 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge) > { > unsigned int year; > > + if (pci_bridge_d3_disable) > + return false; > + > + if (pci_bridge_d3_force) > + return true; > + > /* > * In principle we should be able to put conventional PCI bridges > * into D3. We only support it for PCIe because (a) we want to > @@ -2274,8 +2278,6 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge) > case PCI_EXP_TYPE_ROOT_PORT: > case PCI_EXP_TYPE_UPSTREAM: > case PCI_EXP_TYPE_DOWNSTREAM: > - if (pci_bridge_d3_disable) > - return false; > > /* > * Hotplug interrupts cannot be delivered if the link is down, > @@ -2295,9 +2297,6 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge) > if (bridge->is_hotplug_bridge) > return false; > > - if (pci_bridge_d3_force) > - return true; > - > /* > * It should be safe to put PCIe ports from 2015 or newer > * to D3. We have vague reports of possible hardware > @@ -5708,6 +5707,10 @@ static int __init pci_setup(char *str) > pcie_bus_config = PCIE_BUS_PEER2PEER; > } else if (!strncmp(str, "pcie_scan_all", 13)) { > pci_add_flags(PCI_SCAN_ALL_PCIE_DEVS); > + } else if (!strncmp(str, "bridge_pm", 9)) { > + pci_bridge_d3_force = true; > + } else if (!strncmp(str, "no_bridge_pm", 12)) { > + pci_bridge_d3_disable = true; > } else { > printk(KERN_ERR "PCI: Unknown option `%s'\n", > str); >