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?
