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 <matthias.schiffer@xxxxxxxxxxxxxxx> >> --- >> >> 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
