> 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
On Sun, Dec 25, 2016 at 03:15:52PM +0100, Jethro Beekman wrote:
> On 19-12-16 20:35, Scott Bauer wrote:
> > @@ -1796,6 +1797,13 @@ static void nvme_reset_work(struct work_struct *work)
> > if (result)
> > goto out;
> >
> > + result = nvme_opal_initialize(&dev->ctrl);
> > + if
On 19-12-16 20:35, Scott Bauer wrote:
> @@ -1796,6 +1797,13 @@ static void nvme_reset_work(struct work_struct *work)
> if (result)
> goto out;
>
> + result = nvme_opal_initialize(&dev->ctrl);
> + if (result)
> + goto out;
It seems you always try to intiali
On Tue, Dec 20, 2016 at 10:52:41AM -0700, Scott Bauer wrote:
> 2) Do we want to continue passing around a sed_context to the core?
> Instead of a block_device struct like we did in previous versions.
My personal preference would be the block_device, but in this case my
preference collides with the
On Tue, Dec 20, 2016 at 09:05:32AM -0700, Scott Bauer wrote:
> Thanks Keith. Although TCG Spec currently ignores it in the future it may not.
> In that case we should probably attempt to future proof it a bit. Since the
> namespace ID is accessible via the block device structure I'll find a way to
On Tue, Dec 20, 2016 at 07:46:39AM -0800, Christoph Hellwig wrote:
> On Tue, Dec 20, 2016 at 10:49:16AM -0500, Keith Busch wrote:
> > On Mon, Dec 19, 2016 at 10:17:44PM -0800, Christoph Hellwig wrote:
> > > As far as I can tell Security Send / Receive has always been intended to
> > > apply to the
On 12/20/2016 08:46 AM, Christoph Hellwig wrote:
> On Tue, Dec 20, 2016 at 10:49:16AM -0500, Keith Busch wrote:
>> On Mon, Dec 19, 2016 at 10:17:44PM -0800, Christoph Hellwig wrote:
>>> As far as I can tell Security Send / Receive has always been intended to
>>> apply to the whole controller, eve
On Tue, Dec 20, 2016 at 10:49:16AM -0500, Keith Busch wrote:
> On Mon, Dec 19, 2016 at 10:17:44PM -0800, Christoph Hellwig wrote:
> > As far as I can tell Security Send / Receive has always been intended to
> > apply to the whole controller, even if that's something I would not
> > personally think
On Mon, Dec 19, 2016 at 10:17:44PM -0800, Christoph Hellwig wrote:
> As far as I can tell Security Send / Receive has always been intended to
> apply to the whole controller, even if that's something I would not
> personally think is a good idea.
NVMe security commands required the namespace ID si
> +void nvme_unlock_from_suspend(struct nvme_ctrl *ctrl)
> +{
> + if (opal_unlock_from_suspend(&ctrl->sed_ctx))
> + pr_warn("Failed to unlock one or more locking ranges!\n");
> +}
> +EXPORT_SYMBOL_GPL(nvme_unlock_from_suspend);
I don't think we even need this wrapper. Also for the
> +static int nvme_sec_send(void *ctrl_data, u16 spsp, u8 secp,
> + void *buf, size_t len)
> +{
> + return nvme_sec_submit(ctrl_data, spsp, secp, buf, len,
> +nvme_admin_security_send);
> +}
> +
> +static int nvme_sec_recv(void *ctrl_data, u16 sp
On Mon, Dec 19, 2016 at 03:23:12PM -0700, Scott Bauer wrote:
> I went back and reviewed the spec 1.2.1:
>
> http://www.nvmexpress.org/wp-content/uploads/NVM_Express_1_2_1_Gold_20160603.pdf
> Section 5.18 (page 140->141)
>
> Describes the security send command type and it doesn't have any referenc
Hi Scott,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9 next-20161219]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Scott-Bauer/include-Add-definitions-for-sed/201
On Mon, Dec 19, 2016 at 04:59:54PM -0500, Keith Busch wrote:
> On Mon, Dec 19, 2016 at 12:35:48PM -0700, Scott Bauer wrote:
> > +static int nvme_sec_submit(struct nvme_ctrl *ctrl, u16 spsp, u8 secp,
> > + void *buffer, size_t len, u8 opcode)
> > +{
> > + struct nvme_command c
On Mon, Dec 19, 2016 at 12:35:48PM -0700, Scott Bauer wrote:
> +static int nvme_sec_submit(struct nvme_ctrl *ctrl, u16 spsp, u8 secp,
> +void *buffer, size_t len, u8 opcode)
> +{
> + struct nvme_command cmd = { 0 };
> + struct nvme_ns *ns = NULL;
> +
> + mutex_lo
This patch implements the necessary logic to unlock a SED
enabled device coming back from an S3.
The patch also implements the necessary logic to allocate the
appropriate opal_dev structures to support the OPAL protocol.
Signed-off-by: Scott Bauer
Signed-off-by: Rafael Antognolli
---
drivers/n
16 matches
Mail list logo
