[PATCH 2/4] dm: hash: Add new UCLASS_HASH support

[ChiaWei Wang]

Hi Alex,

> From: Alex G. <mr.nuke.me at gmail.com>
> Sent: Thursday, September 16, 2021 11:43 PM
> 
> Hi,
> 
> On 7/29/21 8:08 PM, Chia-Wei Wang wrote:
> > Add UCLASS_HASH for hash driver development. Thus the hash drivers (SW
> > or HW-accelerated) can be developed in the DM-based fashion.
> 
> Software hashing implementations are shared tightly with host tools.
> With DM, there's no opportunity for code sharing with host tools. The design
> question that I have is "do we want to DM hashes, or do we want to DM
> hardware accelerators for hashes?"
> 
> I did some parallel work expose remaining hash algos via
> hash_lookup_algo() and hash_progressive_lookup_algo().

DM-based approach is mainly for the U-Boot bootloader part.
A consistent, abstract interface is therefore available for vendor drivers regardless of the hashing are conducted in the SW or HW-assisted fashion.
And the CONFIG_SHAxxx_HW_ACCEL/CONFIG_SHA_PROG_HW_ACCEL options can be dropped.

Most of the current DM-based, SW hash driver implementation reuses the code of hash lib.
The code sharing benefit is still greatly leveraged.

> 
> > Signed-off-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>
> > ---
> >   drivers/crypto/Kconfig            |   2 +
> >   drivers/crypto/Makefile           |   1 +
> >   drivers/crypto/hash/Kconfig       |   5 ++
> >   drivers/crypto/hash/Makefile      |   5 ++
> >   drivers/crypto/hash/hash-uclass.c | 121
> ++++++++++++++++++++++++++++++
> >   include/dm/uclass-id.h            |   1 +
> >   include/u-boot/hash.h             |  61 +++++++++++++++
> >   7 files changed, 196 insertions(+)
> >   create mode 100644 drivers/crypto/hash/Kconfig
> >   create mode 100644 drivers/crypto/hash/Makefile
> >   create mode 100644 drivers/crypto/hash/hash-uclass.c
> >   create mode 100644 include/u-boot/hash.h
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index
> > 1ea116be75..0082177c21 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -1,5 +1,7 @@
> >   menu "Hardware crypto devices"
> >
> > +source drivers/crypto/hash/Kconfig
> > +
> Hashes are useful outside of cryptographic functions, so it seems odd to merge
> them in crypto. For example, CRC32 is not a hash useful in crypto, but
> otherwise widely used in u-boot.

Certain systems have the hash functionality included in their crypto engine. (e.g. ARM, FSL, ASPEED, etc.)
Based on this observation, the DM hash driver is placed under crypto/.
However, it is OK for me to move the hash/ out of crypto/ if a more specific place is created and preferred.

> 
> [snip]
> > diff --git a/drivers/crypto/hash/hash-uclass.c
> > b/drivers/crypto/hash/hash-uclass.c
> > new file mode 100644
> > index 0000000000..446eb9e56a
> > --- /dev/null
> > +++ b/drivers/crypto/hash/hash-uclass.c
> > @@ -0,0 +1,121 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2021 ASPEED Technology Inc.
> > + * Author: ChiaWei Wang <chiawei_wang at aspeedtech.com>  */
> > +
> > +#define LOG_CATEGORY UCLASS_HASH
> > +
> > +#include <common.h>
> > +#include <dm.h>
> > +#include <asm/global_data.h>
> > +#include <u-boot/hash.h>
> > +#include <errno.h>
> > +#include <fdtdec.h>
> > +#include <malloc.h>
> > +#include <asm/io.h>
> > +#include <linux/list.h>
> > +
> > +struct hash_info {
> > +	char *name;
> > +	uint32_t digest_size;
> > +};
> > +
> > +static const struct hash_info hash_info[HASH_ALGO_NUM] = {
> > +	[HASH_ALGO_CRC16_CCITT] = { "crc16-ccitt", 2 },
> > +	[HASH_ALGO_CRC32] = { "crc32", 4 },
> > +	[HASH_ALGO_MD5] = { "md5", 16 },
> > +	[HASH_ALGO_SHA1] = { "sha1", 20 },
> > +	[HASH_ALGO_SHA256] = { "sha256", 32 },
> > +	[HASH_ALGO_SHA384] = { "sha384", 48 },
> > +	[HASH_ALGO_SHA512] = { "sha512", 64}, };
> 
> It seems a step backwards to have to enum {} our hash algos, since we already
> identify them by their strings (e.g. "sha256"). and then associated ops structure.
> The
> 
> > +
> > +enum HASH_ALGO hash_algo_lookup_by_name(const char *name)
> 
>      string -> hash_lookup_algo() -> ops struct
> 
> Is the current way to do things. hash_algo_lookup_by_name() does the
> roundabout through an enum. That doesn't make sense to me.
> 

The common hash-uclass.c also provides the string_to_enum conversion.
Both the DM-based hash driver works on both the string-based and enum-based scenario.

Chiawei