Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp440502yba; Wed, 8 May 2019 23:53:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqw1+zrBjnxaZU82akzX5eZE8YfZ7I3sR58P9VVpBbVzHXFdhifXjv30sj8ffxrgU5CZSXdR X-Received: by 2002:a62:1d0d:: with SMTP id d13mr2831097pfd.96.1557384826963; Wed, 08 May 2019 23:53:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557384826; cv=none; d=google.com; s=arc-20160816; b=axaqCJB2z5uHKVyF/9CTfi4EA7y005Y6pmr7nTuXa747MMBaVRndDmGM36HgE3Igxh 7pz9CP5bS7g+mnttHRpgW+UJBnflybMNVjLA99fAF9uP/K1qFYedFkeBCCcebeKUQiuE 9IJej9n0MN+dPYqg15wz8DvQwMCNfb6woztgqhFxbe/WaX8QawHRkwesOPqvCRifWItV wU5s5H1B8B5AY8rmj/P4uQNvBM9EbzIyr/ZiaEAELpkojyXYh9RB1h+Y/zYKzxtMzN3m jsKrGnvosc5NZ/UI1FvottqWWKGm0Kh8SV+ydWG/+OELWOx66OI1/S0srWVsXVtaz78W UG5A== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=+HE/5jinRCAv/V1aeltHJUFXxLv5pXaUaO8Kkc1Bb0M=; b=qL7RKeJ1r7DM/+PWcHfqwERDVj5GluURCPoZ0UtZyt8lIz/vKQ+WKi2403o+cYy6OO 1XqIlTYjTMTPVMTkIC9YqJsNZbGPL0dJhD8nUNMsN+HD8Bb5il4/IVDNevlvMb/ArBZI y2QV4wdHrnn9oz5jjQqiUN3zjIChJkTts8dK9R6NYN/mEGXk7IvFxmUNozfgYLXPVDxK ujgjw4O7i+9HWd5XsYjCIrOmA+6qOYryzGVn2Zk5n1yyAditY/26+MxNBuxPn3P51J79 UrQHmP9L1QrM53L5U6xvEvSa3U18bMBg7sH0M04pPzIIDfzzpvuMbdCqf31WhlbtvPV1 0JIg== 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 cf2si1667841plb.50.2019.05.08.23.53.30; Wed, 08 May 2019 23:53:46 -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 S1726548AbfEIGwo (ORCPT + 99 others); Thu, 9 May 2019 02:52:44 -0400 Received: from verein.lst.de ([213.95.11.211]:43907 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726099AbfEIGwn (ORCPT ); Thu, 9 May 2019 02:52:43 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id F1B9967358; Thu, 9 May 2019 08:52:23 +0200 (CEST) Date: Thu, 9 May 2019 08:52:23 +0200 From: Christoph Hellwig To: Kai-Heng Feng Cc: Christoph Hellwig , rafael.j.wysocki@intel.com, Mario.Limonciello@dell.com, Keith Busch , Keith Busch , Jens Axboe , Sagi Grimberg , linux-nvme , Linux PM , LKML Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle Message-ID: <20190509065223.GA15984@lst.de> References: <20190508185955.11406-1-kai.heng.feng@canonical.com> <20190508191624.GA8365@localhost.localdomain> <3CDA9F13-B17C-456F-8CE1-3A63C6E0DC8F@canonical.com> <20190508195159.GA1530@lst.de> <20190509061237.GA15229@lst.de> <064701C3-2BD4-4D93-891D-B7FBB5040FC4@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <064701C3-2BD4-4D93-891D-B7FBB5040FC4@canonical.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 On Thu, May 09, 2019 at 02:48:59PM +0800, Kai-Heng Feng wrote: > Not really, for hibernation pm_suspend_via_s2idle() evaluates to false so > the old code path will be taken. > >> >> And more to the points - if these "modern MS standby" systems are >> becoming common, which it looks they are, we need support in the PM core >> for those instead of working around the decisions in low-level drivers. > > Rafael, what do you think about this? > Including this patch, there are five drivers that use > pm_suspend_via_{firmware,s2idle}() to differentiate between S2I and S3. > So I think maybe it’s time to introduce a new suspend callback for S2I? We also really need something like that to avoid the PCI_DEV_FLAGS_NO_D3 abuse - that flag is a quirk statically set on a device at probe time to prevent any entering of D3 state. >> per definition, although they might not be too useful. I suspect checking >> APSTA might be safer, but if we don't want to rely on APST we should >> check for a power state supporting the condition that the MS document >> quoted in the original document supports. > > If Modern Standby or Connected Standby is not supported by servers, I > don’t think the design documents mean much here. > We probably should check if the platform firmware really supports S2I > instead. That too. As said this really is a platform decision, and needs to be managed by the platform code through the PM core. Individual drivers like nvme can just implement the behavior, but are the absolute wrong place to make decisions on what kinds of suspend to enter.