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

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ2jRVpQ56_EpVKUMH8E1L2LJ0HgzNCs-GrN9bXfOSXz+Q at mail.gmail.com> you wrote:
> 
> >> +#ifdef USE_HOSTCC
> >> +     crc = htobe32(crc);
> >>       memcpy(output, &crc, sizeof(crc));
> >> +#else
> >> +     put_unaligned_be32(crc, output);
> >> +#endif
> >
> > Why is this depending on USE_HOSTCC, and not on the endianess?
> 
> We always want big-endian in this case, since the bytes have to date
> been written that way by the crc32 command.

Let me rephrase.  Why do we need an #ifdef here, and why depends this
on USE_HOSTCC?

> > And why do we need the #ifdef?  Can we not always use htobe32() and
> > put_unaligned_be32() ?
> 
> Well I don't think put_unaligned_be32 is available to user space,
> which is the environment that the tools are built under. It is
> available in the kernel, but that's not our environment.

It appears put_unaligned_be32() is a widely unknown, pretty exotic
function that so far has been used in ony two source files:

	drivers/usb/gadget/f_mass_storage.c
	lib/tpm.c

The implementation (in "include/linux/unaligned/generic.h") is ugly
and pretty expensive in terms of run time and memory footprint.

I would like to avoid it's usage all together.

> I'm not happy with this solution and would be pleased to find a better
> way, but I'm not sure what it is.

Does the htobe32() + memcpy() approach not work everywhere?

> But this patch does fix a real bug which we should sort out before the
> release, one way or another.

Agreed.

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
"I find this a nice feature but it is not according to  the  documen-
tation. Or is it a BUG?"   "Let's call it an accidental feature. :-)"
                       - Larry Wall in <6909 at jpl-devvax.JPL.NASA.GOV>