Date:   Fri, 10 Mar 2023 18:15:43 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Ard Biesheuvel <ardb@kernel.org>
Cc:     linux-crypto@vger.kernel.org, ebiggers@kernel.org,
        James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH v2] crypto: lib - implement library version of AES in CFB
 mode
Message-ID: <ZAsDT00Jgs2p6luL@gondor.apana.org.au>
References: <20230217144348.1537615-1-ardb@kernel.org>
 <Y/L6rSGDidhhWq2v@gondor.apana.org.au>
 <CAMj1kXE8ZjVh=hLVgnRGr8cJpkqzRHsVxuq3dm1P=Aqc1QpcXg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMj1kXE8ZjVh=hLVgnRGr8cJpkqzRHsVxuq3dm1P=Aqc1QpcXg@mail.gmail.com>
Precedence: bulk

On Mon, Feb 20, 2023 at 08:28:05AM +0100, Ard Biesheuvel wrote:
>
> We would still not have any in-tree users of cfb(aes) or any other
> cfb(*), so in that sense, yes.
> 
> However, skciphers can be called from user space, and we also rely on
> this template for the extended testing of the various cfb() hardware
> implementations that we have in the tree.
> 
> So the answer is no, I suppose. I would like to simplify it a bit,
> though - it is a bit more complicated than it needs to be.

Could we hold onto this for a little bit? I'd like to finally
remove crypto_cipher, and in doing so I will add a virtual address
interface (i.e., not sg) to skcipher like we do with scomp and shash.

Thanks,
-- 
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