[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z_CJFVjAtvhi5Rvy@gondor.apana.org.au>
Date: Sat, 5 Apr 2025 09:36:21 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: T Pratham <t-pratham@...com>
Cc: "David S. Miller" <davem@...emloft.net>, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org, Vignesh Raghavendra <vigneshr@...com>,
Praneeth Bajjuri <praneeth@...com>,
Kamlesh Gurudasani <kamlesh@...com>,
Manorit Chawdhry <m-chawdhry@...com>
Subject: Re: [PATCH RFC 1/2] crypto: ti: Add support for SHA224/256/384/512
in DTHE V2 driver
On Sat, Apr 05, 2025 at 09:33:05AM +0800, Herbert Xu wrote:
>
> This is not unique either. Even the software implementation has
> to deal with this.
>
> This needs to be dealt with in your update function. Simply buffer
> leftover data and only feed whole blocks to the hardware, until
> fina/finup is called.
But it's a bit silly to duplicate code dealing with this common
problem. Since I'm going through every driver for the export format,
I think I will change the calling convention so that non-whole blocks
are dealt with by the API.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists