All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Kai Heng Feng <kai.heng.feng@canonical.com>,
	AceLan Kao <acelan.kao@canonical.com>,
	Keith Busch <keith.busch@intel.com>, Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	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
Date: Fri, 16 Nov 2018 08:49:10 +0100	[thread overview]
Message-ID: <20181116074910.GA13556@lst.de> (raw)
In-Reply-To: <20181115173015.GB229449@google.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3
Date: Fri, 16 Nov 2018 08:49:10 +0100	[thread overview]
Message-ID: <20181116074910.GA13556@lst.de> (raw)
In-Reply-To: <20181115173015.GB229449@google.com>

On Thu, Nov 15, 2018@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.

  reply	other threads:[~2018-11-16  7:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06  7:12 [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3 AceLan Kao
2018-11-06  7:12 ` AceLan Kao
2018-11-06  7:12 ` [PATCH v2 2/2] nvme: add quirk to not call disable function when suspending AceLan Kao
2018-11-06  7:12   ` AceLan Kao
2018-11-09  0:21 ` [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3 Bjorn Helgaas
2018-11-09  0:21   ` Bjorn Helgaas
2018-11-15  7:16   ` Kai Heng Feng
2018-11-15  7:16     ` Kai Heng Feng
2018-11-15 14:58     ` Bjorn Helgaas
2018-11-15 14:58       ` Bjorn Helgaas
2018-11-15 17:30       ` Bjorn Helgaas
2018-11-15 17:30         ` Bjorn Helgaas
2018-11-16  7:49         ` Christoph Hellwig [this message]
2018-11-16  7:49           ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181116074910.GA13556@lst.de \
    --to=hch@lst.de \
    --cc=acelan.kao@canonical.com \
    --cc=axboe@fb.com \
    --cc=helgaas@kernel.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.