[U-Boot] [PATCH 1/4 v7] Exynos: Add hardware accelerated SHA256 and SHA1

[Kim Phillips]

On Thu, 21 Mar 2013 03:12:54 -0400
Akshay Saraswat <akshay.s at samsung.com> wrote:

> >On Mon, 18 Mar 2013 02:06:15 -0400
> >Akshay Saraswat <akshay.s at samsung.com> wrote:
> >
> >> +	while ((readl(&ace_sha_reg->hash_status) & ACE_HASH_MSGDONE_MASK) ==
> >> +		ACE_HASH_MSGDONE_OFF) {
> >> +		/*
> >> +		 * PRNG error bit goes HIGH if a PRNG request occurs without
> >> +		 * a complete seed setup. We are using this bit to check h/w
> >> +		 * because proper setup is not expected in that case.
> >> +		 */
> >> +		if ((readl(&ace_sha_reg->hash_status)
> >> +			& ACE_HASH_PRNGERROR_MASK) == ACE_HASH_PRNGERROR_ON)
> >> +			break;
> >> +	}
> >
> >so we have:
> >
> >whilst (not_done)
> >	if (PRNGERROR_ON)
> >		break;
> >
> >...and then success-assuming code flow continues after this.  What
> >value is this check for PRNGERROR_ON, if the code isn't going to do
> >anything differently?  And what does the status of the RNG have to
> >do with keyless hashing?  It sounds like a check for proper
> >initialization (RNG got seeded) is in order here, but only if it's
> >required for the given hash operations (I doubt it, but the h/w
> >might be fussy).
> 
> PRNG ERROR means setup was not proper which should be the case
> when h/w is faulty because driver does everything in order.

The comment above says:

"PRNG error bit goes HIGH if a PRNG request occurs without
a complete seed setup"

But a SHA request isn't a PRNG request. The h/w shouldn't need the
PRNG at all to perform a simple SHA.

If this is a general initialization/"setup" check, then do it then.
If not, can you do it immediately prior to the wait-for-done after
the "setup"?  A PRNG error shouldn't be going off in the middle of
the wait-for-done loop for a SHA.

> Earlier break was happening which was not correct so changing it to
> "return -EBUSY" which means code flow should not be the same as
> the one being successfull.

-EBUSY?  that means the h/w was busy, and carries a "try again"
implication (much like -EAGAIN) - I doubt that's what's intended
here.

What happened to reverting to s/w, btw?

Kim