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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham 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 64425C04EB8 for ; Tue, 4 Dec 2018 17:55:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3469D20672 for ; Tue, 4 Dec 2018 17:55:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3469D20672 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-pci-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726073AbeLDRzz (ORCPT ); Tue, 4 Dec 2018 12:55:55 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:43779 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726038AbeLDRzz (ORCPT ); Tue, 4 Dec 2018 12:55:55 -0500 Received: from 79.184.252.87.ipv4.supernova.orange.pl (79.184.252.87) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.157) id 3abdd1b8d69e1ef3; Tue, 4 Dec 2018 18:55:52 +0100 From: "Rafael J. Wysocki" To: Mika Westerberg Cc: Bjorn Helgaas , Kedar A Dongre , Lukas Wunner , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH] PCI: Blacklist power management of Gigabyte X299 DESIGNARE EX PCIe ports Date: Tue, 04 Dec 2018 18:55:41 +0100 Message-ID: <6545061.J5ZaFccAEN@aspire.rjw.lan> In-Reply-To: <20181204112048.35378-1-mika.westerberg@linux.intel.com> References: <20181204112048.35378-1-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Tuesday, December 4, 2018 12:20:48 PM CET Mika Westerberg wrote: > Gigabyte X299 DESIGNARE EX motherboard has one PCIe root port that is > connected to an Alpine Ridge Thunderbolt controller. This port has slot > implemented bit set in the config space but other than that it is not > hotplug capable in the sense we are expecting in Linux (it has > dev->is_hotplug_bridge set to 0): > > 00:1c.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5 > Bus: primary=00, secondary=05, subordinate=46, sec-latency=0 > Memory behind bridge: 78000000-8fffffff [size=384M] > Prefetchable memory behind bridge: 00003800f8000000-00003800ffffffff [size=128M] > ... > Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 > ... > SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- > Slot #8, PowerLimit 25.000W; Interlock- NoCompl+ > SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- > Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- > SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- > Changed: MRL- PresDet+ LinkState+ > > This system is using ACPI based hotplug to notify the OS that it needs > to rescan the PCI bus (ACPI hotplug). > > If there is nothing connected in any of the Thunderbolt ports the root > port will not have any runtime PM active children and is thus > automatically runtime suspended pretty soon after boot by PCI PM core. > Now, when a device is connected the BIOS SMI handler responsible for > enumerating newly added devices is not able to find anything because the > port is in D3. > > Prevent this from happening by blacklisting PCI power management of this > particular Gigabyte system. > > Reported-by: Kedar A Dongre > Signed-off-by: Mika Westerberg > --- > I checked booting Windows on the same system and it does not put any of the > PCIe root ports to low power states so there is no issue in Windows. I'm > also quite certain Windows does not have similar blacklist. Well, that only means that Windows uses a different approach to decide whether or not to use PCI PM on PCIe root ports (but we knew that that would be the case upfront, didn't we?). > I wonder if our pci_bridge_d3_possible() heuristics would need to be > refined somehow? At least if this blacklist starts growing. Because Windows uses a different approach here, there will be systems for which Linux will decide to use PCI PM with PCIe root ports and Windows won't (or vice versa). That will cause Linux to use configurations that have not been validated against Windows, so it is likely that some of them will not work. Hence, the need for a blacklist is not a surprise really. So Reviewed-by: Rafael J. Wysocki BTW, what version of Windows you have tested?