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

[Tom Rini <trini@ti.com>]

On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
> Hi Wolfgang,
> 
> On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk <wd@denx.de> wrote:
> 
> > > 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).
> 
> Indeed; I would suggest splitting this change in two independent ones:
> 
> - fix the endianness issue: change the endianness of crc through the
>   use of htonl() but leave the existing memcpy() in place as it is,
>   even though it is not speed-optimized. That's what Simon's patch
>   does if the HOSTCC part is ignored;
> 
> - fix the unalignment issue by changing parameter 'output' of function
>   type 'hash_func_ws' from u8* to u32* and adjusting the rest of the
>   code accordingly -- which would lead to replacing the crc32 final
>   memcpy() with a single indirect assignment.
> 
> These two changes could be submitted either separately, or as a series.

Now so that I'm clear, if we don't do anything about the unaligned issue
today, it's just slow, not an unaligned access that leads to abort,
right?  So part one today for release, part two next week after release.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130418/897b16e2/attachment.pgp>