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@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
