[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250613145108.GB1287@sol>
Date: Fri, 13 Jun 2025 07:51:08 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Ard Biesheuvel <ardb@...nel.org>, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mips@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-s390@...r.kernel.org, sparclinux@...r.kernel.org,
x86@...nel.org, Jason@...c4.com, torvalds@...ux-foundation.org
Subject: Re: [PATCH 07/16] crypto: sha512 - replace sha512_generic with
wrapper around SHA-512 library
On Fri, Jun 13, 2025 at 04:39:10PM +0800, Herbert Xu wrote:
> On Fri, Jun 13, 2025 at 09:38:11AM +0200, Ard Biesheuvel wrote:
> >
> > Perhaps I am just slow, but could you please explain again what the
> > point is of all these changes?
> >
> > Where is h/w accelerated ahash being used to the extent that it
> > justifies changing all this existing code to accommodate it?
>
> There are two separate changes.
>
> First of all the export format is being made consistent so that
> any hardware hash can switch over to a software fallback after
> it has started, e.g., in the event of a memory allocation failure.
>
> The partial block API handling on the other hand is about simplifying
> the drivers so that they are less error-prone.
Is it perhaps time to reconsider your plan, given that it's causing problems for
the librarification effort which is much more useful, and also most of the
legacy hardware offload drivers seem to be incompatible with it too?
- Eric
Powered by blists - more mailing lists