All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] crc32: Correct endianness of crc32 result
Date: Thu, 18 Apr 2013 18:39:29 +0200	[thread overview]
Message-ID: <20130418183929.4ec73ae3@lilith> (raw)
In-Reply-To: <20130418143909.192F720019A@gemini.denx.de>

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.

Amicalement,
-- 
Albert.

  reply	other threads:[~2013-04-18 16:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 23:11 [U-Boot] [PATCH] crc32: Correct endianness of crc32 result Simon Glass
2013-04-05 23:32 ` Allen Martin
2013-04-06  7:04 ` Wolfgang Denk
2013-04-16 21:57   ` Simon Glass
2013-04-16 23:00     ` Tom Rini
2013-04-16 23:16       ` Simon Glass
2013-04-17  5:40     ` Wolfgang Denk
2013-04-17 18:28       ` Simon Glass
2013-04-17 19:23         ` Albert ARIBAUD
2013-04-17 20:59           ` Simon Glass
2013-04-18  6:20             ` Albert ARIBAUD
2013-04-18 10:36               ` Wolfgang Denk
2013-04-18 11:18                 ` Albert ARIBAUD
2013-04-18 14:39                   ` Wolfgang Denk
2013-04-18 16:39                     ` Albert ARIBAUD [this message]
2013-04-18 16:58                       ` Tom Rini
2013-04-18 18:43                         ` Albert ARIBAUD
2013-04-18 19:06                           ` Simon Glass
2013-04-18 19:18                             ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130418183929.4ec73ae3@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.