Hi Simon, > -----Original Message----- > From: Simon Glass <s...@chromium.org> > Sent: Wednesday, July 21, 2021 2:33 AM > > Hi Chia-Wei, > > On Tue, 20 Jul 2021 at 00:38, Chia-Wei Wang > <chiawei_w...@aspeedtech.com> wrote: > > > > From: Joel Stanley <j...@jms.id.au> > > > > Hash and Crypto Engine (HACE) is designed to accelerate the throughput > > of hash data digest, and symmetric-key encryption. > > > > Signed-off-by: Joel Stanley <j...@jms.id.au> > > Signed-off-by: Chia-Wei Wang <chiawei_w...@aspeedtech.com> > > --- > > drivers/crypto/Kconfig | 2 + > > drivers/crypto/Makefile | 1 + > > drivers/crypto/aspeed/Kconfig | 12 ++ > > drivers/crypto/aspeed/Makefile | 1 + > > drivers/crypto/aspeed/aspeed_hace.c | 308 > > ++++++++++++++++++++++++++++ > > 5 files changed, 324 insertions(+) > > create mode 100644 drivers/crypto/aspeed/Kconfig create mode 100644 > > drivers/crypto/aspeed/Makefile create mode 100644 > > drivers/crypto/aspeed/aspeed_hace.c > > This hash interface is wonky. > > There should be a hash uclass and this driver should be in that uclass. The > existing hw_... functions should be dropped. > > Please let me know if you need further guidance, but basically, we need a > proper uclass and driver.
I am thinking to take the UCLASS_MOD_EXP as an example to create UCLASS_HASH. This UCLASS_HASH should provide .ops callback like UCLASS_MOD_EXP do to support both SW and HW implemented HSAH. Is this a right direction to start with? In addition, adding UCLASS_HASH may involve lots of common code modification. Should we make it part of the current patch series? Or a new patch series after this one? Thanks, Chiawei