[U-Boot] [PATCH] crc32: Correct endianness of crc32 result

[Wolfgang Denk]

Dear Albert,

In message <20130418131810.38c916b8 at lilith> you wrote:
> 
> > OK - and what about the other architectures that suffer from the same
> > issues?
> 
> They should/could provide their own optimized versions, obviously.

Well, if this was a generally needed or even useful service, that
might make sense.  But it is highly exotic stuff...

> > I really dislike introducing such custom functions when we have
> > standard functions available that implement the same purposes.
> 
> I understand the point; this is a classical opposition of generic vs
> optimized.

Not really.  It is more opposition against premature optimization at
the cost of non-standard code.

Is there any justification that we really need hightly optimized
versus generic code here?  Is this used anywhere in a place where
performance is critical?

> > Can we not stick to standard functions?  Instead of htobe32() we
> > should use htonl() which is available both in U-Boot and in the host
> > environment.
> 
> Note that there are two problems here: endianness conversion and
> unaligned storage. We can indeed use htoln() instead of htobe32(), but
> that only affects/solved endianness issues, not alignment ones, for
> which there is no solution that is efficient across all ARM targets.

Correct.  But the htobe32() approach was cobining this with the
generic memcpy(), too, so we would do the same with htoln().

> So how about changing the element type of output in the definition of
> hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
> sha256_csum_wd and crc32_wd_buf, and adapting the output argument
> of the sole call to hash_func_ws, that is, the local "u8
> output[HASH_MAX_DIGEST_SIZE];" in hash.c? Then we'be done with
> alignment.

OK, but that would be a totally different approach (which appears to
be a good one, here).

> Note finally that we *need* unaligned access macros/inline
> functions/whatever, if only for exceptions laid out in
> doc/README.arm-unaligned-accesses. If we avoid calling them too often,
> we can live with generic.

Agreed; the focus should always be on avoidance, though.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
    \|/ ____ \|/                                     \|/ ____ \|/
     @~/ ,. \~@                                       @~/ ,. \~@
    /_( \__/ )_\                                     /_( \__/ )_\
       \__U_/                                           \__U_/