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;
Date:   Tue, 11 Aug 2020 10:59:04 +1000
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Horia =?utf-8?Q?Geant=C4=83?= <horia.geanta@nxp.com>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        Stephan Mueller <smueller@chronox.de>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Eric Biggers <ebiggers@kernel.org>
Subject: Re: [v3 PATCH 19/31] crypto: caam - Remove rfc3686 implementations
Message-ID: <20200811005903.GB24901@gondor.apana.org.au>
References: <20200728071746.GA22352@gondor.apana.org.au>
 <E1k0JtR-0006Rx-Oq@fornost.hmeau.com>
 <92042403-0379-55ab-ccbc-4610555f0a93@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <92042403-0379-55ab-ccbc-4610555f0a93@nxp.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 10, 2020 at 07:47:40PM +0300, Horia Geantă wrote:
>
> I would prefer keeping the caam rfc3686(ctr(aes)) implementation.
> It's almost cost-free when compared to ctr(aes), since:
> -there are no (accelerator-)external DMAs generated
> -shared descriptors are constructed at .setkey time
> -code complexity is manageable

The reason I'm removing it is because it doesn't support chaining.
We could keep it by adding chaining support which should be trivial
but it's something that I can't test.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt