All of lore.kernel.org
 help / color / mirror / Atom feed
From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH] nvme: simplify stripe quirk
Date: Thu, 15 Dec 2016 10:59:58 -0500	[thread overview]
Message-ID: <20161215155958.GA29688@localhost.localdomain> (raw)
In-Reply-To: <20161215083236.GA32244@infradead.org>

On Thu, Dec 15, 2016@12:32:36AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 14, 2016@07:10:55PM -0500, Keith Busch wrote:
> > Some subsystem vendors believe they own the Identify Controller vendor
> > specific region, and will repurpose it with their own values.
> 
> Well, it's vendor specific, right?

If I'm the vendor and you're the subsystem vendor, who owns the vendor
specific region?
 
> I don't understand this patch at all - you hardcode a value that was
> previously vendor specific, and your argument for that is that the
> vendor specific value is used by the value - heck, that's exactly why
> the value is there.

I'm not sure what you mean. I haven't hard-coded anything. The alignment
requirements on the hardware itself always matches MDTS, so that's what
the patch proposes to use.

The current driver expects ID_CTRL.VS[3] defines the stripe use. However,
a subsystem vendor changes the field to mean something completely
different that has nothing to do with backend striping. We can't trust
how to decode the field just by knowing the VID:DID anymore, and I'm
confident we don't want to add another layer of SVID:SSID checks to know
how to decode quirk.

Instead, I'm simplifying this by exploiting a fact about the hardware. If
you're wondering why we didn't do that in the first place, it's because we
considered making this a changeable property, but that never materialized
and it never will.

  reply	other threads:[~2016-12-15 15:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-15  0:10 [PATCH] nvme: simplify stripe quirk Keith Busch
2016-12-15  8:32 ` Christoph Hellwig
2016-12-15 15:59   ` Keith Busch [this message]
2016-12-16  8:07     ` Christoph Hellwig
2016-12-16 15:48       ` Keith Busch
2016-12-17  7:13         ` 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=20161215155958.GA29688@localhost.localdomain \
    --to=keith.busch@intel.com \
    /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.