On Tue, 12 Mar 2013 16:40:38 -0700 Simon Glass <s...@chromium.org> wrote:
> Hi Kim, > > On Tue, Mar 12, 2013 at 12:32 PM, Kim Phillips > <kim.phill...@freescale.com> wrote: > > On Mon, 11 Mar 2013 17:53:37 -0700 > > Simon Glass <s...@chromium.org> wrote: > > > >> On Mon, Mar 11, 2013 at 5:44 PM, Kim Phillips > >> <kim.phill...@freescale.com>wrote: > >> > On Thu, 7 Mar 2013 19:11:16 -0800 > >> > Simon Glass <s...@chromium.org> wrote: > >> > > OK so let's look at adding the hash_register() idea. But not in this > >> > > series. That should come later in a revision of the hash.c > >> > > infrastructure, since it needs to adjust sha1, sha255 and crc32. > >> > > >> > I don't understand: why not s/ace/hw/g in common/ and include/ on > >> > this patchseries, then move straight to the device model at some > >> > later point? It's a compromise, but it works fine for the time > >> > being - other vendors can add their hash support without having to > >> > touch common code, code size is not affected, etc. > >> > >> Fine with me. The effect is the same - this is just a rename. Should not be > >> done in the ace.h file though, only in the naming of the functions called > >> from hash.c, right? > > > > the ace_sha_hash_digest() declaration should be removed from > > ace_sha.h (it's only needed by the driver, which is ok without it > > being there). ACE_SHA_TYPE_SHA* definitions belong in the driver > > too - they're ACE h/w-specific. Rename the filename ace_sha.h to > > hw_sha.h, and all remaining ACE references contained in it. > > Maybe I misunderstand - are you saying that that all the ACE symbols > in the driver should be renamed to hw? That doesn't make a lot of > sense to me - why is this needed? no, only the entry points to the driver should be renamed - they are currently called ace_sha{1,256}(). The include/ace_sha.h file as it is currently can be made completely h/w agnostic. Kim _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot