From: helgaas@kernel.org (Bjorn Helgaas)
Subject: [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3
Date: Thu, 15 Nov 2018 11:30:15 -0600 [thread overview]
Message-ID: <20181115173015.GB229449@google.com> (raw)
In-Reply-To: <20181115145809.GA207836@google.com>
On Thu, Nov 15, 2018@08:58:09AM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 15, 2018@03:16:29PM +0800, Kai Heng Feng wrote:
> > On Nov 9, 2018,@08:21, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > I'm not sure we want a quirk for this at all, since as Christoph
> > > points out, it doesn't fix a functional issue as the other uses of
> > > quirk_no_ata_d3() do.
> > >
> > > From your emails with Christoph, it sounds like this quirk is a
> > > workaround for a firmware defect. If we *do* end up wanting a quirk,
> > > the changelog should at least mention the firmware defect and maybe
> > > check whether it has been fixed.
> >
> > According to SK Hynix folks and new evidence on the new Intel NVMe
> > we have, this is something we are going to see more often.
>
> Hmmm, are you suggesting that if we went this quirk route, we'd be
> updating the quirk frequently to add new devices?
>
> I'm opposed to that as a strategy because it makes needless work. You
> have to update the quirk, backport it to older kernels, re-release
> distro kernels, etc.
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 :)
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kai Heng Feng <kai.heng.feng@canonical.com>
Cc: 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: Thu, 15 Nov 2018 11:30:15 -0600 [thread overview]
Message-ID: <20181115173015.GB229449@google.com> (raw)
In-Reply-To: <20181115145809.GA207836@google.com>
On Thu, Nov 15, 2018 at 08:58:09AM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 15, 2018 at 03:16:29PM +0800, Kai Heng Feng wrote:
> > On Nov 9, 2018, at 08:21, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > I'm not sure we want a quirk for this at all, since as Christoph
> > > points out, it doesn't fix a functional issue as the other uses of
> > > quirk_no_ata_d3() do.
> > >
> > > From your emails with Christoph, it sounds like this quirk is a
> > > workaround for a firmware defect. If we *do* end up wanting a quirk,
> > > the changelog should at least mention the firmware defect and maybe
> > > check whether it has been fixed.
> >
> > According to SK Hynix folks and new evidence on the new Intel NVMe
> > we have, this is something we are going to see more often.
>
> Hmmm, are you suggesting that if we went this quirk route, we'd be
> updating the quirk frequently to add new devices?
>
> I'm opposed to that as a strategy because it makes needless work. You
> have to update the quirk, backport it to older kernels, re-release
> distro kernels, etc.
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 :)
Bjorn
next prev parent reply other threads:[~2018-11-15 17:30 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 [this message]
2018-11-15 17:30 ` Bjorn Helgaas
2018-11-16 7:49 ` Christoph Hellwig
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=20181115173015.GB229449@google.com \
--to=helgaas@kernel.org \
/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.