Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp2550625pxt; Mon, 9 Aug 2021 03:22:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyJV8RoiWjVIIoMBi02GLF9BqySX+nQ4Ct9bAcxV3U6PKwyYCI70bWqntnLGZdGb36LrCC X-Received: by 2002:a17:906:6686:: with SMTP id z6mr21702332ejo.539.1628504573954; Mon, 09 Aug 2021 03:22:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628504573; cv=none; d=google.com; s=arc-20160816; b=nS33uqe/oTt/6EoVjMmy96luUK7RF1GfypkDkmFEvFZz+QqeuFvc0/4MOaWoyBam2K NZMJdpAr0l1Fig7M/Q6hhHRI/gQ5ClyLNLsjlap48EsMestGJlojmYNNPokf1XmUiT7G plkdjk+Im/o+rY1srKg90Awldg0kN8Ujk71OuzZYYG+xF7tAZBu7VdllevEQuhM0BYVN o/uEQ1YxOHv83NhIhXr4rzXCmKxG2VvQUtOfDGsKplJrWynzOfx1xOeORQSknwO94kto LmLihKRWsu7HDAA/HgYIv2wYn0uW7vGTM6pNpyWk56z7N8/hBaxIqvX4E9jUqISF04Pk 1ebQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=/KFgD13Rpwl6CVmcHwcqVZoCeIxstv2lcgpNG+78H9o=; b=oEL9bGOCSPGrEmBJyikzxrX3M0JChLzxGdJZuAX8eMrj0dHaT85eYefpAARbn5kgGQ 5g/JlFdHFlPSq+oaNKAUHgj49h1ukWP6SYxXnEoq+puqL5Dr7/zfRGZ/C1Kznb3szlzV bLoRotBKjzQL//QRYqaFY7dcQRP78TZIK532eDLx2C0bjmA74HwnDWu/j2SrlVcDz7Oh wKZPbSVj1tDhDoX21hCf+5xjElfJmz3Sy3CRKimBfqMxVGMl/g70RKSwFLHHBu0//ToN cvALdHwM4w1HDZGOsz5gjH658QmHDYfLTTtR/2NttY89Abxz+GLePHTDCULmYWZTSXCh frYw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d17si40656eds.604.2021.08.09.03.22.31; Mon, 09 Aug 2021 03:22:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234717AbhHIJrz (ORCPT + 99 others); Mon, 9 Aug 2021 05:47:55 -0400 Received: from bmailout2.hostsharing.net ([83.223.78.240]:45819 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234365AbhHIJrz (ORCPT ); Mon, 9 Aug 2021 05:47:55 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 2F86F2800B3D2; Mon, 9 Aug 2021 11:47:31 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 1733A260B31; Mon, 9 Aug 2021 11:47:31 +0200 (CEST) Date: Mon, 9 Aug 2021 11:47:31 +0200 From: Lukas Wunner To: Kai-Heng Feng Cc: bhelgaas@google.com, Sean V Kelley , Jonathan Cameron , Qiuxu Zhuo , Kuppuswamy Sathyanarayanan , Keith Busch , "open list:PCI SUBSYSTEM" , open list , Mika Westerberg Subject: Re: [PATCH] PCI/portdrv: Disallow runtime suspend when waekup is required but PME service isn't supported Message-ID: <20210809094731.GA16595@wunner.de> References: <20210713075726.1232938-1-kai.heng.feng@canonical.com> <20210809042414.107430-1-kai.heng.feng@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210809042414.107430-1-kai.heng.feng@canonical.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [cc += Mika] On Mon, Aug 09, 2021 at 12:24:12PM +0800, Kai-Heng Feng wrote: > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213873 The last comment on this bugzilla says "BIOS will fix this." and the status is RESOLVED WILL_NOT_FIX. Why is the patch still necessary? > Some platforms cannot detect ethernet hotplug once its upstream port is > runtime suspended because PME isn't enabled in _OSC. If PME is not handled natively, why does the NIC runtime suspend? Shouldn't this be fixed in the NIC driver by keeping the device runtime active if PME cannot be used? > Disallow port runtime suspend when any child device requires wakeup, so > pci_pme_list_scan() can still read the PME status from the devices > behind the port. pci_pme_list_scan() is for broken devices which fail to signal PME. Is this NIC really among them or does PME fail merely because it's not granted to OSPM? > --- a/drivers/pci/pcie/portdrv_pci.c > +++ b/drivers/pci/pcie/portdrv_pci.c > @@ -59,14 +59,30 @@ static int pcie_port_runtime_suspend(struct device *dev) > return pcie_port_device_runtime_suspend(dev); > } > > +static int pcie_port_wakeup_check(struct device *dev, void *data) > +{ > + struct pci_dev *pdev = to_pci_dev(dev); > + > + if (!pdev) > + return 0; > + > + return pdev->wakeup_prepared; > +} > + > static int pcie_port_runtime_idle(struct device *dev) > { > + struct pci_dev *pdev = to_pci_dev(dev); > + > + if (!pcie_port_find_device(pdev, PCIE_PORT_SERVICE_PME) && > + device_for_each_child(dev, NULL, pcie_port_wakeup_check)) > + return -EBUSY; > + > /* > * Assume the PCI core has set bridge_d3 whenever it thinks the port > * should be good to go to D3. Everything else, including moving > * the port to D3, is handled by the PCI core. > */ > - return to_pci_dev(dev)->bridge_d3 ? 0 : -EBUSY; > + return pdev->bridge_d3 ? 0 : -EBUSY; If an additional check is necessary for this issue, it should be integrated into pci_dev_check_d3cold() instead of pcie_port_runtime_idle(). Thanks, Lukas