Date: Wed, 28 Dec 2016 00:39:56 -0800
From: Christoph Hellwig <hch@infradead.org>
To: Scott Bauer <scott.bauer@intel.com>
Cc: Jethro Beekman <kernel@jbeekman.nl>, keith.busch@intel.com,
        sagi@grimberg.me, hch@infradead.org, Rafael.Antognolli@intel.com,
        linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
        axboe@fb.com, viro@zeniv.linux.org.uk, jonathan.derrick@intel.com
Subject: Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED
 Allocation code.
Message-ID: <20161228083955.GA2811@infradead.org>
References: <1482176149-2257-1-git-send-email-scott.bauer@intel.com>
 <1482176149-2257-5-git-send-email-scott.bauer@intel.com>
 <3d8b8516-aac6-c11c-dbbb-47fc01308f8c@jbeekman.nl>
 <20161227221221.GA2902@sbauer-Z170X-UD5>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161227221221.GA2902@sbauer-Z170X-UD5>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 777
Lines: 12

> for OPAL. In order to determine if the controller supports opal we need to allocate
> the previously mentioned structures anyway. I want to stay away from making payloads
> (specifically discovery0 ) payload in the nvme driver and allow the opal core to do a
> all the grunt work. In the future we'll probably have to refactor the core a bit to do
> just packet generation. It looks like at least for NVMe we're going to have to do a discovery
> to figure out whether we've got mutiple locking ranges per NS or just one global lr during
> initialization.

We might have to do discovery in the nvme driver - there also is the
ATA security feature supported by various consumer drives.  Jethro has
been doing some work in that direction, although driven by userspace
for now.