Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5410466yba; Wed, 8 May 2019 12:53:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxaevrhMHlcqxrMwZBkA8EaW8f3wUjBSZk/cIHrA6P7actNw6Hefw6JOJFv8kpzrxx0OX3c X-Received: by 2002:a62:ae05:: with SMTP id q5mr26873797pff.13.1557345231352; Wed, 08 May 2019 12:53:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557345231; cv=none; d=google.com; s=arc-20160816; b=W42reWDzOeRqjYDakwgGVk5bAkJqhsG5bWHcIiO+OlLcg35OuGxBclL1Uuf25Sbbw8 BKggoXJ4stKhys2vmIGzRKSQse9svfBIjSkNGQ+1qjqhHP+20qiL8lIv5Q6Eeq8UsV6C d4XxwR2ndqWFwCuoct9XCDWY8IbeNbxRUwWuADdHyrS8HbWVqK0IKm8ZfPMT+68fPAYi RnGCYqD6Jrh4jF9bMILRSyG+9+B7idLLj3wz00qbAB2/9e3wX60FD/KKkN9et93Q20jf VfXXSVlxmlQsKueugg0vGHVr4OM/QnqbdmdrXdtBNyyHoTRYd/dzyXCIPD5YgyoKCryt 3QvQ== 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=fVcXe1B3CfF9Kg905s5K2q21p9vZZiIVlqsjQvrTvWc=; b=ulc2c32xk1heOO6ijAg6o7uSenYpM9plsOWcRcmnHNjrNqSFkNVsxrxqwVrW2PE/Yk 6y4/9PYwvGdHM4UgN4yOdPSwCftjzuyGpQdW8YpZgro+E6tSeTMb36fERiKvt7RPqFnU Nzq0G1VZ5jlpc9acuuYQAEeIxb2MGdhcGJfvQEx9KaOfPN24skSguFaHPjF5LC+lBtpS n4emuF3MoK25QZJ1XVhoN/77aOSnu5vfYQE2aN8MY8ewgKxRQcHDQ4PHuaVpBACWW4f4 wMJYzkTb2A+OSM4sFMb7fwRgJXp60+cdlIrIZJPTjh5OYJb31WDshq96ytlzfq9otVVS iXdw== 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 d34si14673048pgd.558.2019.05.08.12.53.35; Wed, 08 May 2019 12:53:51 -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 S1728167AbfEHTwT (ORCPT + 99 others); Wed, 8 May 2019 15:52:19 -0400 Received: from verein.lst.de ([213.95.11.211]:41592 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726852AbfEHTwS (ORCPT ); Wed, 8 May 2019 15:52:18 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 465E167358; Wed, 8 May 2019 21:51:59 +0200 (CEST) Date: Wed, 8 May 2019 21:51:59 +0200 From: Christoph Hellwig To: Mario.Limonciello@dell.com Cc: kai.heng.feng@canonical.com, kbusch@kernel.org, keith.busch@intel.com, axboe@fb.com, hch@lst.de, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle Message-ID: <20190508195159.GA1530@lst.de> References: <20190508185955.11406-1-kai.heng.feng@canonical.com> <20190508191624.GA8365@localhost.localdomain> <3CDA9F13-B17C-456F-8CE1-3A63C6E0DC8F@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, May 08, 2019 at 07:38:50PM +0000, Mario.Limonciello@dell.com wrote: > The existing routines have an implied assumption that firmware will come swinging > with a hammer to control the rails the SSD sits on. > With S2I everything needs to come from the driver side and it really is a > different paradigm. And that is why is this patch is fundamentally broken. When using the simple pm ops suspend the pm core expects the device to be powered off. If fancy suspend doesn't want that we need to communicate what to do to the device in another way, as the whole thing is a platform decision. There probabl is one (or five) methods in dev_pm_ops that do the right thing, but please coordinate this with the PM maintainers to make sure it does the right thing and doesn't for example break either hibernate where we really don't expect just a lower power state, or enterprise class NVMe devices that don't do APST and don't really do different power states at all in many cases.