Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Horia Geanta <horia.geanta@nxp.com>
To:     Matthias Schiffer <matthias.schiffer@ew.tq-group.com>,
        Aymen Sghaier <aymen.sghaier@nxp.com>
CC:     "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] crypto: caam: re-init JR on resume
Thread-Topic: [RFC] crypto: caam: re-init JR on resume
Thread-Index: AQHV2nuUMVzJk05YSUGngOodcu7wgw==
Date:   Tue, 25 Feb 2020 14:53:34 +0000
Message-ID: <VI1PR0402MB348516318CA986084CBE7B5C98ED0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
References: <20200203101850.22570-1-matthias.schiffer@ew.tq-group.com>
 <eca3c07767f2451590496bc890b235c8285f1a0b.camel@ew.tq-group.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fd17ca9c-4ffa-4a5e-044b-08d7ba027cc9
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 14:53:34.1424
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: m5lJIiI+RpttHDauafGipldppdvA8ejl2Bm7uUBb2lGvxgmb5Tj6BnbgyYMHGssshn+GOyUtfO2S59hgdcQZwg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB2800
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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