Re: [PATCH 0/8] eMMC inline encryption support

[Adrian Hunter <adrian.hunter@intel.com>]

On 20/11/20 9:44 pm, Eric Biggers wrote:
> Hi Adrian,
> 
> On Fri, Nov 20, 2020 at 09:29:59PM +0200, Adrian Hunter wrote:
>> I haven't had a chance to look at it properly, but I do have a couple of
>> dumb questions.  How do you ensure the host controller is not runtime
>> suspended when the key is programmed?
> 
> This is handled by the block layer, in block/keyslot-manager.c.  It ensures that
> the device is resumed before calling blk_ksm_ll_ops::keyslot_program() or
> blk_ksm_ll_ops::keyslot_evict().  See blk_ksm_hw_enter().

Cool, although cqhci is doing a lazy kind of resume, so maybe not be enabled
when a key is programmed?  Would that be a problem?

> 
>> Are the keys lost when the host controller is reset, and then how do you know
>> the host controller does not get reset after the key is programmed but before
>> the I/O is submitted?
> 
> As with UFS, keys might be lost when the host controller is reset, so we're
> reprogramming all the keys when that happens.  See patch 1:
> 
>     mmc_set_initial_state()
>         mmc_crypto_set_initial_state()
>             blk_ksm_reprogram_all_keys()
> 
> (That's the intent, at least.  For MMC, I'm not sure if resets were properly
> covered by the testing I've done so far.  But the code looks right to me.)

After reset, cqhci will not necessarily be enabled at this point.  Is that OK?