On 2/21/2020 10:43 AM, Matthias Schiffer wrote:
> On Mon, 2020-02-03 at 11:18 +0100, Matthias Schiffer wrote:
>> The JR loses its configuration during suspend-to-RAM (at least on
>> i.MX6UL). Re-initialize the hardware on resume.
>>
>> Signed-off-by: Matthias Schiffer <[email protected]>
>> ---
>>
>> I've come across the issue that the CAAM would not work anymore after
>> deep sleep on i.MX6UL. It turned out that the CAAM loses its state
>> during suspend-to-RAM, so all registers read as zero and need to be
>> reinitialized.
>>
>> This patch is my first attempt at fixing the issue. It seems to work
>> well enough, but I assume I'm missing some synchronization to prevent
>> that some CAAM operation is currently under way when the suspend
>> happens? I don't know the PM and crypto subsystems well enough to
>> judge
>> if this is possible, and if it is, how to prevent it.
>>
>> I've only compile-tested this version of the patch, as I had to port
>> it
>> from our board kernel, which is based on the heavily-modified NXP
>> branch.
>
> It would be great to get some feedback on this patch. Is the hardware
> support to lose its state? Does my fix look correct?
>
For most parts, yes, CAAM HW block loses state.
We are working at upstreaming PM support.
A non-exhaustive high-level list of things to be done, on top of your patch:
-caam controller driver (ctrl.c) also needs support for PM,
for e.g. RNG has to be reinitialized when resuming
-caam/jr driver: a few other registers have to be saved & restored
-caam/jr driver: flush/abort the jobs in the input ring when suspending
-implementations of algorithms using "split key" (a.k.a. "derived key"),
which is a black / encrypted key, have to convert the key to
a persistent blob since KEKs (JDKEK, TDKEK, TDSK registers) are lost
and in certain cases cannot be restored to initial values
Horia