[PATCH] Add support for SHA384 and SHA512

[Tom Rini]

On Fri, May 29, 2020 at 04:47:23PM +1200, Reuben Dowle wrote:

> > Two general comments.  First, please use CONFIG_IS_ENABLED() to test for
> > the new symbols so that we won't have any growth in SPL if we have one
> > of these enabled in the main binary but NOT SPL.
> 
> It is not clear to me how I should be using CONFIG_IS_ENABLED(). I
> have copied the pattern of macro checks from the SHA256 code, and this
> does not use this anywhere. Take for example common\hash.c - this is
> checking for #if defined(CONFIG_SHA256) or #ifdef CONFIG_SHA256, so I
> added similar checks.
> 
> It also seems that existing SHA etc algorithms are enabled in SPL
> using non-standard macros like 'CONFIG_SPL_SHA1_SUPPORT' when in main
> uboot the macro is CONFIG_SHA1. I tried attempting to fix these issues
> - renaming CONFIG_SPL_SHA384_SUPPORT to CONFIG_SPL_SHA384, then using
> the CONFIG_IS_ENABLED() macros, but I am running into a lot of
> problems getting the tools (eg mkimage) to compile. In image.h there
> is logic like:
> 
> #if defined(CONFIG_FIT_ENABLE_SHA256_SUPPORT) || \
>     defined(CONFIG_SPL_SHA256_SUPPORT)
> #define IMAGE_ENABLE_SHA256    1
> #else
> #define IMAGE_ENABLE_SHA256    0
> #endif
> 
> So I think the hash algorithms are not using same method as other
> parts of code to control the SPL/non SPL parts, probably because of
> the interdependancy with the host tools. Fixing all this up to me
> seems a separate task to just adding a new hash algorithm.
> 
> What would you advise?

OK, thanks.  So long as this is following the existing style, I'll take
a look and see if we get any unexpected binary growth from this.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200605/51d348c3/attachment.sig>