[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211011180058.GA635062@dhcp-10-100-145-180.wdc.com>
Date: Mon, 11 Oct 2021 11:00:58 -0700
From: Keith Busch <kbusch@...nel.org>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: Jens Axboe <axboe@...com>, Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
linux-nvme@...ts.infradead.org,
LKML <linux-kernel@...r.kernel.org>, Dell.Client.Kernel@...l.com
Subject: Re: SK hynix BC511: warning: nvme nvme0: missing or invalid SUBNQN
field.
On Mon, Oct 11, 2021 at 03:08:15PM +0200, Paul Menzel wrote:
> Am 17.08.21 um 19:02 schrieb Keith Busch:
> >
> > In the section for "Identify Controller Data Structure" (section
> > 5.17.2.1, figure 257 in spec version 2.0), the NQN definition says:
> >
> > "Support for this field is mandatory if the controller supports revision
> > 1.2.1 or later"
> >
> > The driver does confirm the controller's reported revision meets this
> > requirement before emitting the warning.
>
> The Dell support came back to me, and said, that Hynix refuses to publish a
> fixed firmware unless I show them a use case, where I need that field.
>
> Can somebody think of a use case,
Spec compliance certification. UNH test 1.1 case 2, for example.
> and why this field was made mandatory in
> the specification?
A dependable way to uniquely identify a specific device is generally
useful. The NVMe TWG determined the previous methods were inadequate.
The linux kernel will continue to use the device without this capability
since the low level driver doesn't need it to interact with a
controller, but the driver will warn about the non-compliance in case
host software is relying on this field.
Powered by blists - more mailing lists