Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Tero Kristo <t-kristo@ti.com>
To:     <herbert@gondor.apana.org.au>, <davem@davemloft.net>,
        <linux-crypto@vger.kernel.org>
Subject: [PATCHv2 0/7] crypto: TI SA2UL crypto accelerator support
Date:   Fri, 24 Apr 2020 19:44:23 +0300
Message-ID: <20200424164430.3288-1-t-kristo@ti.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi,

This is 2nd revision of the series [1] Keerthy posted quite a while back,
I've sort of adopted the series for now. Compared to v1, there has been
pretty major re-design I've done across the driver to fix any review
comments, fix any bugs I've encountered, and get the full crypto
self-test suite working with the driver, including the extra tests.
I've also tested the driver with tcrypt and IPSec suite just to root out
any issues. This series applies on top of 5.7-rc1 also and has no
dependencies. The DTS patches are provided for reference here only, and
should be merged separately via ARM SoC tree once the driver is ready.

There is maybe one aspect of the driver I am somewhat uncertain myself,
and that is the init/update/final handling with the hash algorithm
support, or the caching part of it actually. If someone calls the device
with init+update sequences never finalizing the data, we end up with
memory leaks. Any thoughts on that how to handle it? I could maybe add
some timeout to purge stale buffers or alternatively just drop to SW
fallback completely for non-digest type hashing, but that would prevent
openssl/devcrypto from using the crypto accelerator completely; it uses
init+update+final sequence heavily.

-Tero

[1] https://patchwork.kernel.org/cover/11021337/


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki