Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2685997ybk; Mon, 18 May 2020 05:36:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXh70GzdOTBT37F8iSgAZTmn9Bmlalck/P4N0cC40eejz9jOCPAGWe9dsG7svy8peWI3CP X-Received: by 2002:a50:be8f:: with SMTP id b15mr12685252edk.182.1589805407082; Mon, 18 May 2020 05:36:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589805407; cv=none; d=google.com; s=arc-20160816; b=czEai0HVv7e9vA9wmpAkM4dQL6BX7qQhlHbl7syUzhfg7Z4/AS4o6QHl3wJyuHnWmd o8KZitEVFpGXiYEPI7nLxHbsYIz/bi5lyh9tVphnncGQlQrqKT2YHM2RnpnGr+qtW5vJ Mhy+q54ON15gCpNBWtcqSkk7HE2Eob1t0TNL2pSc+SX1283mew1bYFSGZUysgkEW2BaU LbrJY10g3f5ui6ceQP54DyZl9ykX3A01W2C5ELCqM61syoNusz385vtMwx+37RLYXsXY 9JqWh8IdAzXG9zZFXtcGBlLfJ7cZH8W5Tq1BK8fRTJc2wtPmvvgwES4uMKbVGtLiYQiM UwfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=657DSUOGsY8BPxd8jN2tmMIg4i+aY2DSGay7r0iBeMI=; b=EH5piuuTKnbII7U64xJD6bpM8mgxrZ6EkaBmtoCkNDp9Zwa6c327EpsgfWzs1zfB97 HIoCZWKyToCc1dANv7ldQn2tSIsiZReBCEYBBTBamMugXKbXwQLKJC6AHZ6vPkjWHLfR terW12Xo+o8j9re0SVVMZWJV2JIoW42xzuJZx9mSSnt9LSqkBpIE+9/5m6MVtV0wAKEo 39W7NvOxVgef00f1qMcqGSTdmJnrvX7T9Zzgvylp3dxD1z5hV67i0z0lAA96gosXEKxj 28lZQP8peP65fcPZKOXXLWAX9xtMlBKi+CvLBQV8NEl29cByHmCHH2ethfayHOtcofGW xV8g== 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 rp1si1079199ejb.392.2020.05.18.05.36.24; Mon, 18 May 2020 05:36:47 -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 S1727123AbgERMei (ORCPT + 99 others); Mon, 18 May 2020 08:34:38 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:55816 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726800AbgERMeh (ORCPT ); Mon, 18 May 2020 08:34:37 -0400 Received: from 89-64-86-21.dynamic.chello.pl (89.64.86.21) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.415) id 240662dfe3aa87da; Mon, 18 May 2020 14:34:34 +0200 From: "Rafael J. Wysocki" To: "David E. Box" Cc: lenb@kernel.org, bhelgaas@google.com, kbusch@kernel.org, axboe@fb.com, hch@lst.de, sagi@grimberg.me, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Dan Williams Subject: Re: [PATCH 1/2] pci: Add ACPI StorageD3Enable _DSD support Date: Mon, 18 May 2020 14:34:33 +0200 Message-ID: <1967525.XL736rHnAO@kreacher> In-Reply-To: <20200428003214.3764-2-david.e.box@linux.intel.com> References: <20200428003214.3764-1-david.e.box@linux.intel.com> <20200428003214.3764-2-david.e.box@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, April 28, 2020 2:32:13 AM CEST David E. Box wrote: > NVMe storage power management during suspend-to-idle, particularly on > laptops, has been inconsistent with some devices working with D3 while > others must rely on NVMe APST in order for power savings to be realized. > Currently the default is to use APST unless quirked to do otherwise. > However newer platforms, like Intel Comet Lake systems, may require NVMe > drives to use D3 in order for the PCIe ports to be properly power managed. > To make it easier for drivers to choose, these platforms may supply a > special "StorageD3Enable" _DSD property under the root port that the device > is attached to. If supplied, the driver must use D3 in order for the > platform to realize the deepest power savings in suspend-to-idle. > > Adds support for the _DSD to the pci/acpi layer. > > Acked-by: Dan Williams > Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro > Signed-off-by: David E. Box > --- > drivers/acpi/property.c | 3 +++ > drivers/pci/pci-acpi.c | 47 +++++++++++++++++++++++++++++++++++++++++ > drivers/pci/pci.c | 6 ++++++ > drivers/pci/pci.h | 4 ++++ > include/linux/pci.h | 1 + > 5 files changed, 61 insertions(+) > > diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c > index e601c4511a8b..f09375ab40e4 100644 > --- a/drivers/acpi/property.c > +++ b/drivers/acpi/property.c > @@ -45,6 +45,9 @@ static const guid_t prp_guids[] = { > /* Thunderbolt GUID for WAKE_SUPPORTED: 6c501103-c189-4296-ba72-9bf5a26ebe5d */ > GUID_INIT(0x6c501103, 0xc189, 0x4296, > 0xba, 0x72, 0x9b, 0xf5, 0xa2, 0x6e, 0xbe, 0x5d), > + /* D3 Support for storage devivce: 5025030f-842f-4ab4-a561-99a5189762d0 */ > + GUID_INIT(0x5025030f, 0x842f, 0x4ab4, > + 0xa5, 0x61, 0x99, 0xa5, 0x18, 0x97, 0x62, 0xd0), > }; > > /* ACPI _DSD data subnodes GUID: dbb8e3e6-5886-4ba6-8795-1319f52a966b */ > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c > index d21969fba6ab..5df249ebf022 100644 > --- a/drivers/pci/pci-acpi.c > +++ b/drivers/pci/pci-acpi.c > @@ -972,6 +972,52 @@ static bool acpi_pci_bridge_d3(struct pci_dev *dev) > return val == 1; > } > > +static bool acpi_pci_storage_d3(struct pci_dev *dev) > +{ > + const struct fwnode_handle *fwnode; > + struct acpi_device *adev; > + struct pci_dev *root; > + acpi_handle handle; > + acpi_status status; > + u8 val; > + > + /* > + * Look for _DSD property specifying that the storage device on > + * the port must use D3 to support deep platform power savings during > + * suspend-to-idle > + */ > + root = pci_find_pcie_root_port(dev); > + if (!root) > + return false; > + > + adev = ACPI_COMPANION(&root->dev); > + if (root == dev) { > + /* > + * It is possible that the ACPI companion is not yet bound > + * for the root port so look it up manually here. > + */ > + if (!adev && !pci_dev_is_added(root)) > + adev = acpi_pci_find_companion(&root->dev); > + } > + > + if (!adev) > + return false; > + > + status = acpi_get_handle(adev->handle, "PXSX", &handle); > + if (ACPI_FAILURE(status)) > + return false; > + > + adev = acpi_bus_get_acpi_device(handle); > + if (!adev) > + return false; > + > + fwnode = acpi_fwnode_handle(adev); > + if (!fwnode_property_read_u8(fwnode, "StorageD3Enable", &val)) > + return val == 1; > + > + return false; > +} Kind of orthogonal to what happens to the second patch in this series, I don't think that the PCI changes below are all needed. IMO it would be sufficient to export the function above, maybe as pci_acpi_storage_d3(), to drivers, so that they can call it directly as desired. Since _DSD return data are not allowed by the spec to change between subsequent invocations of it, the interested driver may call this function once at the device init time and quirk it accordingly if needed. Cheers!