On Fri, Dec 18, 2020 at 07:40:41AM +0800, Peng.Zhou wrote: > > > Hi Eric, > > > > > > I also have a question about reprogramming keys scenarios, if some SoC > > > vensors' eMMC host will power down or something else like that keys will > > > be lost after runtime suspend, that means we must do reprogramming keys > > > in runtime resume, right? Do you think that we should add it in > > > cqhci-core layer(such as __cqhci_enable()) or every SoC vendor's host > > > driver resume path? > > > > > > > The keys should only be lost on reset, not on runtime suspend. So I believe the > > code I've proposed is sufficient. > > > > - Eric > > That's a little too absolute for me...anyway that's my concern for much > more SoC vendors who want to be compatible with your framework in > future.Thank you for explanation. But the current approach works on all the hardware that's been tested so far, right? And programming the keys can take a long time, so it shouldn't be done unnecessarily. (I've heard it's fairly fast on Mediatek SoCs. However, with Qualcomm ICE it takes longer.) It seems that host controller configuration typically doesn't get lost during runtime suspend, and the keyslots are no exception to that. And if (hypothetically) a host controller that adds crypto support in the future actually does need to restore the keys during runtime resume, it can just do it in its ->runtime_resume() method. So from what I can see, there isn't anything else we should do for now. - Eric
