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

Wolfgang Denk
2013-04-17T05:40:47Z

Dear Simon Glass,

In message <CAPnjgZ2jRVpQ56_EpVKUMH8E1L2LJ0HgzNCs-GrN9bXfOSXz+Q@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@jpl-devvax.JPL.NASA.GOV>