Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2965814yba; Sat, 11 May 2019 00:27:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqxsGnORtuQXEh78wFDHqc1syKgxK2jGsP0g0zP3ZAhsJZRhf1biGfFUcr9p6hkCoMCobKeI X-Received: by 2002:a17:902:a415:: with SMTP id p21mr4310495plq.286.1557559675165; Sat, 11 May 2019 00:27:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557559675; cv=none; d=google.com; s=arc-20160816; b=WfRoZjmpWG5B07UNMoVx4+a8P2GFtbYaGT07hxaw1g+mM6enVEFbqfXzS0Z0ReCpYa HST7UJ/1QffYAzF+xF8dxPsMKqH3vh+T4PwY3j2HzVS9+Zua+itpc3VUSipTRXooiovt UgpkDqLX/u/65Baoq+Xm269XI116NU58g4a26kqUBxOh6Yv/cE0CCs4foGdxXMae+jW/ 9JGo0AacZZ6UeBEuP+IZLPQoTPNP5jR6poC96bQ71/XE4akZFUXzvB30br1yHHielWho 4skF7PWwrrIbLwYQAL/xOUZzVwuVUOH5s8t8q2e+6I8ltPBBpA/+8FgIG5prQTUzrE4/ akPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=hokQ7mFPbV0DOO2uYGJNNJWtgc7n5Y+XGp9B5Q0zsY0=; b=IY4tf4x0TWvYNDkFyaBtcm/DekI3eGav8aRfODukYJAklyYYxe9/Nk1p+pGbZXH5gc gZSOtmNUK+qPB2/Xa/qOoJIsR9ArqCfxmhs4VH04aSZm0ki0z2VVaF2jdpJVttR/bhUW NE3beN7a2RvZYtk5Oq9dXzm0Vvungajfye4mho+74YJnFTJ31gI6cz/q574FKFIei8c3 Xh+AIw5Z7je8hkYCuiLWZFXPqStfeRR5j5bxLjDSq00ZOU70V6NbLOo6u8XNv5DIA2Md UrTmq+hZArVp/D2zxPFy9C89X/DDtrR7BKRvvgBFnyl9wrli8yIvJqrQABgJkaSPn7Ag 39/A== ARC-Authentication-Results: i=1; mx.google.com; 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 v200si9911929pgb.366.2019.05.11.00.27.06; Sat, 11 May 2019 00:27:55 -0700 (PDT) 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; 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 S1728449AbfEKHXU (ORCPT + 99 others); Sat, 11 May 2019 03:23:20 -0400 Received: from verein.lst.de ([213.95.11.211]:56604 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726849AbfEKHXU (ORCPT ); Sat, 11 May 2019 03:23:20 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 2FA1068AFE; Sat, 11 May 2019 09:22:59 +0200 (CEST) Date: Sat, 11 May 2019 09:22:58 +0200 From: Christoph Hellwig To: Keith Busch Cc: Christoph Hellwig , Sagi Grimberg , linux-nvme@lists.infradead.org, Rafael Wysocki , lkml , linux-pm , Mario Limonciello , Kai Heng Feng Subject: Re: [PATCH] nvme/pci: Use host managed power state for suspend Message-ID: <20190511072258.GB14764@lst.de> References: <20190510212937.11661-1-keith.busch@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190510212937.11661-1-keith.busch@intel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A couple nitpicks, mostly leftover from the previous iteration (I didn't see replies to those comments from you, despite seeing a reply to my mail, assuming it didn't get lost): > +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned ps) > +{ > + return nvme_set_features(ctrl, NVME_FEAT_POWER_MGMT, ps, NULL, 0, NULL); > +} > +EXPORT_SYMBOL_GPL(nvme_set_power); > + > +int nvme_get_power(struct nvme_ctrl *ctrl, u32 *result) > +{ > + struct nvme_command c; > + union nvme_result res; > + int ret; > + > + if (!result) > + return -EINVAL; > + > + memset(&c, 0, sizeof(c)); > + c.features.opcode = nvme_admin_get_features; > + c.features.fid = cpu_to_le32(NVME_FEAT_POWER_MGMT); > + > + ret = __nvme_submit_sync_cmd(ctrl->admin_q, &c, &res, > + NULL, 0, 0, NVME_QID_ANY, 0, 0, false); > + if (ret >= 0) > + *result = le32_to_cpu(res.u32); > + return ret; > +} > +EXPORT_SYMBOL_GPL(nvme_get_power); At this point I'd rather see those in the PCIe driver. While the power state feature is generic in the spec I don't see it actually being used anytime anywhere else any time soon. But maybe we can add a nvme_get_features helper ala nvme_set_features in the core to avoid a little boilerplate code for the future? > + ret = nvme_set_power(&dev->ctrl, dev->ctrl.npss); > + if (ret < 0) > + return ret; I can't find any wording in the spec that guarantees the highest numerical power state is the deepest. But maybe I'm just missing something as such an ordering would be really helpful? > static int nvme_suspend(struct device *dev) > { > struct pci_dev *pdev = to_pci_dev(dev); > struct nvme_dev *ndev = pci_get_drvdata(pdev); > > + /* > + * Try to use nvme if the device supports host managed power settings > + * and platform firmware is not involved. > + */ This just comments that what, but I think we need a why here as the what is fairly obvious..