Re: [PATCH RFC 1/2] crypto: ti: Add support for SHA224/256/384/512 in DTHE V2 driver

[Herbert Xu <herbert@gondor.apana.org.au>]

On Fri, Apr 04, 2025 at 03:45:22PM +0530, T Pratham wrote:
>
> Although, I was not able to quite understand what you meant to imply
> from this snippet. And I was not able to find any references for
> HASH_FBREQ_ON_STACK as well. Overall, it was not clear why such a fbreq
> is required and where it is being used. Hence I omitted this part
> completely, and still passing all tests. Would love to know if you have
> any good reason to what you suggested.

The HASH_FBREQ_ON_STACK is part of the revamped ahash interface
that I'm working on right now.  I think you should wait for that
to be merged before reposting your driver as it would make your
job a lot easier.

> Another thing, the buflen variable ranges from 0 to BLOCK_SIZE, not
> (BLOCK_SIZE - 1). This is being used to handle certain quirks of the
> hardware together with linux crypto framework, which I am happy to
> elaborate further if required. Cutting the digression short, I have to
> find a workaround to comply with your import/export changes:

Yes that's a common problem with crypto hash drivers that can't
deal with a zero-length final update.  The best solution is to
use a fallback for the final update if it turns out to be zero-length
rather than retaining an extra block.  Hashing a single block for
finalisation is simply not worth the overhead of setting up DMA and
what not.

The other option is to use the fallback to hash the extra block in
the export function.

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