[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161228083955.GA2811@infradead.org>
Date: Wed, 28 Dec 2016 00:39:56 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Scott Bauer <scott.bauer@...el.com>
Cc: Jethro Beekman <kernel@...ekman.nl>, keith.busch@...el.com,
sagi@...mberg.me, hch@...radead.org, Rafael.Antognolli@...el.com,
linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
axboe@...com, viro@...iv.linux.org.uk, jonathan.derrick@...el.com
Subject: Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED
Allocation code.
> 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.
Powered by blists - more mailing lists