Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp144933imu; Thu, 15 Nov 2018 23:50:03 -0800 (PST) X-Google-Smtp-Source: AJdET5dYaALU4XWDp55sXYDKMOQgTEQzWgoqjXCR9Xd+nKsES+oOz/PpGI6+wxCIEyheiEUQtC2R X-Received: by 2002:a63:b16:: with SMTP id 22mr8914906pgl.306.1542354603651; Thu, 15 Nov 2018 23:50:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542354603; cv=none; d=google.com; s=arc-20160816; b=ctPof0Mh9OcxCx+V7gykt5lQiDuXYupOtzbF4t7uK3cpfMTQfga09gc/muSg1J6jcs piWlm2GSqp++3q0C0wmYspWO4Zh9g/32bpSv3jXL6f6iGAXKA4/69CJ2pSdf1/Y5t1oV SVEnx4D2eNDZHZci7byNLMMn3j5iqtiPI/cwlnmlld8e1u2RsXZbOECgmZGAi8hB+9CU mmmnys9dq3Ubmj48rg8LD88cb0uM4fBpMCLaQAbYcbQszGQNSGVpS9Ff1hZPRdwXlHNH FzjZmEn222dNdkqFfc4E/eoyTKvqeLb06g+DBBLFJm+ZpyH+lZ5pjva72yRq/6JAQEfS ASZQ== 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=9Da3hdMCmoKGWUwXtmb616RX+lJqjvUw4H/y3uWEjfw=; b=Po03i9Qx8r9kdvf8nQ2zDQnmwaB/KevrFJzkK0yYyvqg8U2hA0LC2bq4ytEHey7L6Q MVuIoLPYBNZ+WVquw6xWXJ32YZFzVN55dptvYWYPe+VpjKZublYgMmEfFodt4arAHjtX iN4gWRVaPjHppwAdFcKaxuXWp1BIRerUGvZ9fdUmk0WaCet4TpWa/6lcHyTthXqFRsu+ 05tNR4+T2CmwLDGOzWztFTVRgucC2jdWSKuoyKxIgY7deC3eParqrPWUsYI5zmNnWAES PVXb5YyabBrrrXPjb/mlCH/cVF3S05xVFV5/80a9fiF8tkbBcc0zc7HZQ82dbMv16KMD NL/Q== 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 b15si10375914plm.431.2018.11.15.23.49.48; Thu, 15 Nov 2018 23:50:03 -0800 (PST) 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 S2389066AbeKPSAZ (ORCPT + 99 others); Fri, 16 Nov 2018 13:00:25 -0500 Received: from verein.lst.de ([213.95.11.211]:47678 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727380AbeKPSAZ (ORCPT ); Fri, 16 Nov 2018 13:00:25 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 9623968D60; Fri, 16 Nov 2018 08:49:10 +0100 (CET) Date: Fri, 16 Nov 2018 08:49:10 +0100 From: Christoph Hellwig To: Bjorn Helgaas Cc: Kai Heng Feng , AceLan Kao , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3 Message-ID: <20181116074910.GA13556@lst.de> References: <20181106071214.12745-1-acelan.kao@canonical.com> <20181109002157.GK41183@google.com> <20181115145809.GA207836@google.com> <20181115173015.GB229449@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181115173015.GB229449@google.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, Nov 15, 2018 at 11:30:15AM -0600, Bjorn Helgaas wrote: > > But I guess you have to do this anyway just to add the vendor/device > ID to the driver, so maybe this isn't a big deal to you. If you can > do a quirk like this in the driver, it would be invisible to me and I > wouldn't care. I just don't want to deal with ongoing tweaks like > this in the PCI core :) No, NVMe is a spec with a class code, and a specification that is vendor independent. NVMe devices declare invididual features based on common fields. APST is an optional feature with all kinds of parameters, but there is absolutely no language that a host should not put the device into D3 mode if APST is supported anywhere in the NVMe spec, and such behavior is also rather counter intuitive. If SK Hynix thinks this is sensible behavior they should bring it up in the NVMe technical working group. I've pinged a contact there to see what this whole story is about.