On Fri, Mar 22, 2019 at 4:45 PM Dan Williams <dan.j.williams(a)intel.com> wrote:
On Fri, Mar 22, 2019 at 4:40 PM Dave Jiang <dave.jiang(a)intel.com> wrote:
>
> Adding support to allow secure erase to happen when security state is not
> enabled. Key data of 0's will be passed in.
>
> Signed-off-by: Dave Jiang <dave.jiang(a)intel.com>
> ---
>
> v2:
> - Make patch header explicitly zero key (Dan)
> - Declare global static zero key (Dan)
> - Make nfit_test explicitly test zero key (Dan)
Looks good. I'm going to add a sentence to the changelog pointing out
that the kernel is already supporting a zero key for some of the other
security interfaces. That makes this effectively a fix to unify
semantics across commands, i.e. something I can reasonably justify as
a commit that needs to be backported to v5.0 and suitable for v5.1-rc.
Actually, now that I check we're now supporting the concept of a
zero-key differently across commands. The existing semantic is that
NULL key data means "use zero key" to the Intel command
implementation. Can you respin this with the note about it being a fix
to unify semantics across DIMMs and the send a follow on cleanup to
switch the other key-id-0 cases to use the new zero key rather than
require the ops implementations to special case "NULL" key data?