linux-kernel - Re: [PATCH] crypto: caam - enable crypto-engine retry mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bae6b3d7-582a-c9fc-c118-992d780ef5ed@nxp.com>
Date:   Mon, 26 Oct 2020 19:57:59 +0200
From:   Horia Geantă <horia.geanta@....com>
To:     Iuliana Prodan <iuliana.prodan@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Aymen Sghaier <aymen.sghaier@....com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Silvano Di Ninno <silvano.dininno@....com>,
        Franck Lenormand <franck.lenormand@....com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        Andrei Botila <andrei.botila@....com>,
        Dragos Rosioru <dragos.rosioru@....com>
Subject: Re: [PATCH] crypto: caam - enable crypto-engine retry mechanism

On 10/26/2020 7:11 PM, Iuliana Prodan wrote:
> On 10/26/2020 5:36 PM, Horia Geantă wrote:
>> On 10/21/2020 11:07 PM, Iuliana Prodan wrote:
[...]
>>> +#define CRYPTO_ENGINE_MAX_QLEN (2 * (JOBR_DEPTH - THRESHOLD))
>>> +
>> What's the logic behind multiplying by 2?
> 
> I added the 2 as the number of Job Rings.
> My logic was that crypto-engine is one per CAAM (x no of JRs), while 
> JOB_DEPTH is per JR.
Currently there is one crypto-engine per JR.
crypto_engine_alloc_init() is called when caam/jr driver is probing.

> I know there are targets with other than 2 JRs. Therefore, is there a 
> way to get this number automatically?
> 
Most SoCs have CAAM configured with 4 JRs.
Of course what's visible to the kernel might be different.

Given there's one crypto-engine / JR, determining the number of JRs
shouldn't be required.

Horia