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

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

On 04/04/25 15:53, Herbert Xu wrote:
> 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,

Although yes the hardware cannot process zero length input, the actual
reason for doing this is to support the linux framework's
init-update-final flow on the hardware.

Our hardware can accept data as multiple packets, each of which can be
of any length. The only restriction it has is that only the last packet
can have arbitrary length, rest have to be a multiple of BLOCK_SIZE. The
hardware needs a bit to be set to indicate that the packet to be
submitted is the last data packet.

Now, in the crypto framework, there is no way to know if a particular
update call is the last update or if another update call will happen
after that. Therefore I am unable to set that bit in any invocation of
the update function. So I am retaining one block of data which is sent
to hardware in the final function, a place where we know for sure that
there is no more input coming now.

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