From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752782AbdBFVSx (ORCPT ); Mon, 6 Feb 2017 16:18:53 -0500 Received: from mailout2.hostsharing.net ([83.223.90.233]:53099 "EHLO mailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752185AbdBFVSw (ORCPT ); Mon, 6 Feb 2017 16:18:52 -0500 Date: Mon, 6 Feb 2017 22:20:41 +0100 From: Lukas Wunner To: Bjorn Helgaas Cc: Yinghai Lu , "Rafael J. Wysocki" , Mika Westerberg , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend Message-ID: <20170206212041.GC679@wunner.de> References: <20170206175405.GA15565@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170206175405.GA15565@bhelgaas-glaptop.roam.corp.google.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote: > On Mon, Feb 06, 2017 at 06:54:37AM +0100, Lukas Wunner wrote: > > Since commit 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe > > hotplug ports") we runtime suspend a hotplug port to D3hot when all its > > children are runtime suspended or none are present. > > > > When runtime suspending the port the PCI core automatically enables PME: > > pci_pm_runtime_suspend() > > pci_finish_runtime_suspend() > > __pci_enable_wake() > > > > According to the PCI Express Base Specification, section 6.7.3.4: > > "Note that PME and Hot-Plug Event interrupts (when both are > > implemented) always share the same MSI or MSI-X vector [...] > > If wake generation is required by the associated form factor > > specification, a hot-plug capable Downstream Port must support > > generation of a wakeup event (using the PME mechanism) on hotplug > > events that occur when the system is in a sleep state or the Port > > is in device state D1, D2, or D3Hot." > > > > Thus, if the port is runtime suspended even though it is still occupied, > > it may immediately be woken by a PME interrupt. > > The spec goes on to say that a wakeup event should be generated when > all three of these conditions occur: > > - status register for an enabled [hotplug] event transitions from > not set to set > > - Port is in D1, D2, or D3hot, > > - PME_En is set > > I think you're saying that if we put a hotplug-capable port that > controls an occupied slot into D3hot, the port may immediately > generate a wakeup PME. > > What is the hotplug event that causes generation of this wakeup event? If you had read all e-mails in this thread or looked at the bugzilla entry I've created, you wouldn't have to ask this question. I think it's disappointing that you're asking me to jump through various hoops like creating a bugzilla entry, as well as threatening to revert my patch, but are unwilling to even look at the bugzilla entry or read the entire thread. It is equally disappointing that the reporter of the regression was unwilling or unable to provide dmesg output for both machines so that we've got no real idea what we're dealing with. It's a Link Up event. Which doesn't make sense of course because per the spec PME is only supposed to be signaled when the Link Status *changes* from 0 to 1, which is not supposed to happen for a slot that has been manually disabled. It's a quirk of this (unknown) hardware. > > PME is in fact unnecessary on hotplug ports: Hotplug can be signaled > > even in D3hot, > > How are hotplug events signaled in D3hot without using PME? I'm > looking at the PCI PM spec, r1.2, table 5-4 (p 49 in my copy), which > says a function in D3hot can only generate PME. The table doesn't seem to be in congruence with reality. The hotplug ports on Thunderbolt chips emit hotplug interrupts in D3hot regardless of PME. The Broadcom wireless cards I submitted an early quirk for last year likewise emitted interrupts in D3hot. Lukas