Am 12. Mai 2021 19:32:42 MESZ schrieb Simon Glass sjg@chromium.org:
Hi Heinrich,
On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 12.05.21 18:05, Simon Glass wrote:
Hi Heinrich,
On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt
xypron.glpk@gmx.de wrote:
On 17.02.21 04:20, Joel Stanley wrote:
Similar to support for SHA1 and SHA256, allow the use of hardware
hashing
engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL
/
CONFIG_SHA_PROG_HW_ACCEL.
Signed-off-by: Joel Stanley joel@jms.id.au
This merged patch leads to errors compiling the EFI TCG2 protocol
on
boards with CONFIG_SHA_HW_ACCEL.
There is not as single implementation of hw_sha384 and hw_sha512.
You
could only use CONFIG_SHA_HW_ACCEL for selecting these functions
if
these were implemented for *all* boards with
CONFIG_SHA_HW_ACCEL=y. But
this will never happen.
*This patch needs to be reverted.*
Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak
functions
instead?
This is all a mess. We should not use weak functions IMO, but
instead
have a driver interface, like we do with filesystems.
Part of the challenge is the need to keep code size small for platforms that only need one algorithm.
If a function is not referenced, the linker will eliminate it. But
with
a driver interface every function in the interface is referenced.
Indeed, but we can still have an option for enabling the progressive interface. My point is that the implementation (software or hardware) should use a driver.
Regards, Simon
Anyway that should not stop us from reverting a problematic patch. We can work on refactoring afterwards.
Best regards
Heinrich