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

[T Pratham <t-pratham@ti.com>]

Hi Herbert

On 02/04/25 19:01, T Pratham wrote:
> Hi Herbert
>
> On 02/03/25 13:39, Herbert Xu wrote:
>> On Tue, Feb 18, 2025 at 04:19:42PM +0530, T Pratham wrote:
>>> +struct dthe_hash_ctx {
>>> +	enum dthe_hash_algSel mode;
>>> +	u16 block_size;
>>> +	u8 digest_size;
>>> +	u8 phash_available;
>>> +	u32 phash[SHA512_DIGEST_SIZE / sizeof(u32)];
>> Is this format identical to the software sha512 hash? If so please
>> make the export/import functions translate to and from struct
>> sha512_state.
>>
>> That way we can export and resume using the software sha512 in case
>> something goes wrong (e.g., memory allocation failure).
>>
>> Ditto with all the other hash algorithms.
>>
>> Thanks,
> [...]
>
> You are correct in the sense that the format is /mostly/ identical to
> struct sha512_state. phash[], data_buf[] and digestcnt are same as in
> sha512_state. Rest of the members I can reinitialize at import. The only
> one which stores some kind of state is *buflen*, which requires its
> value to be restored while importing. The current driver implementation
> processes input in multiples of block size and stores the remainder data
> in data_buf[] if the input is not a multiple of block size. buflen has
> the length of data in data_buf[].
>
> [...]
>
I'm so sorry, for it slipped out of my mind that `u8 phash_available`
also needs to be restored at import. It's just stores a boolean 0/1. How
to go about handling this?
Thanks for your help.

Regards
T Pratham <t-pratham@ti.com>