From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] lib:crc32: Allow setting of the initial crc32 value
Date: Mon, 05 May 2014 19:47:30 +0200 [thread overview]
Message-ID: <20140505174730.B1E413809DA@gemini.denx.de> (raw)
In-Reply-To: <1399295277-28334-1-git-send-email-l.majewski@samsung.com>
Dear Lukasz,
In message <1399295277-28334-1-git-send-email-l.majewski@samsung.com> you wrote:
> The current approach set the initial value of crc32 calculation to zero,
> which is correct for calculating checksum of the whole chunk of data.
>
> It however, lacks the flexibility, when one wants to calculate CRC32 of
> a file comprised of many smaller parts received separately.
>
> In the proposed approach the output value is used as a starting condition
> for the proper crc32 calculation at crc32_wd function. This behavior is
> identical to the one provided by crc32() method implementation.
>
> Additionally, comments were appropriately updated.
>
> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Simon Glass <sjg@chromium.org>
> ---
> include/hash.h | 2 +-
> include/u-boot/crc.h | 3 ++-
> lib/crc32.c | 2 +-
> 3 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/hash.h b/include/hash.h
> index dc21678..abf704d 100644
> --- a/include/hash.h
> +++ b/include/hash.h
> @@ -101,7 +101,7 @@ int hash_command(const char *algo_name, int flags, cmd_tbl_t *cmdtp, int flag,
> * @algo_name: Hash algorithm to use
> * @data: Data to hash
> * @len: Lengh of data to hash in bytes
> - * @output: Place to put hash value
> + * @output: Place to put hash value - also the initial value (crc32)
> * @output_size: On entry, pointer to the number of bytes available in
> * output. On exit, pointer to the number of bytes used.
> * If NULL, then it is assumed that the caller has
> diff --git a/include/u-boot/crc.h b/include/u-boot/crc.h
> index 754ac72..7a87911 100644
> --- a/include/u-boot/crc.h
> +++ b/include/u-boot/crc.h
> @@ -19,7 +19,8 @@ uint32_t crc32_no_comp (uint32_t, const unsigned char *, uint);
> *
> * @input: Input buffer
> * @ilen: Input buffer length
> - * @output: Place to put checksum result (4 bytes)
> + * @output: Place to provide initial CRC32 value and afterwards
> + * put checksum result (4 bytes)
> * @chunk_sz: Trigger watchdog after processing this many bytes
> */
> void crc32_wd_buf(const unsigned char *input, uint ilen,
> diff --git a/lib/crc32.c b/lib/crc32.c
> index 9759212..f6266c7 100644
> --- a/lib/crc32.c
> +++ b/lib/crc32.c
> @@ -257,7 +257,7 @@ void crc32_wd_buf(const unsigned char *input, unsigned int ilen,
> {
> uint32_t crc;
>
> - crc = crc32_wd(0, input, ilen, chunk_sz);
> + crc = crc32_wd(*(uint32_t *)output, input, ilen, chunk_sz);
> crc = htonl(crc);
> memcpy(output, &crc, sizeof(crc));
This looks wrong to me, in a number of ways.
First, the *(uint32_t *)output cast, is likely to trigger unaligned
accesses with the resulting problems on some platforms. Never, never
ever cast a character pointer into something that requires any
alignment!
Seconds, where exactly do you now initialize the CRC vlaue to start
with 0 ?
Finally we should keep in mind (this is nothing caused by your patch,
but when touching this area we really should consider it) that we have
a number of (slightly) different CRC implementations thare cry for
cleanup / unification: in addition to lib/crc32.c we have
disk/part_efi.c (which provides efi_crc32()), drivers/mtd/ubi/crc32.c
(which provides crc32_le() and crc32_be()), net/eth.c (which uses
ether_crc()), we have BZ2_crc32Table[256] in lib/bzlib_private.h /
lib/bzlib_crctable.c (which appears to be unsued), and we have
tools/pblimage.c (which provides pbl_crc32()).
What a mess :-(
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
What is tolerance? -- it is the consequence of humanity. We are all
formed of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature. - Voltaire
next prev parent reply other threads:[~2014-05-05 17:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 13:07 [U-Boot] [PATCH] lib:crc32: Allow setting of the initial crc32 value Lukasz Majewski
2014-05-05 17:47 ` Wolfgang Denk [this message]
2014-05-05 18:56 ` Marek Vasut
2014-05-06 5:54 ` Lukasz Majewski
2014-05-05 17:51 ` Marek Vasut
2014-05-07 6:10 ` [U-Boot] [PATCH v2] " Lukasz Majewski
2014-05-07 8:25 ` Marek Vasut
2014-05-07 10:17 ` Lukasz Majewski
2014-05-07 10:42 ` Wolfgang Denk
2014-05-07 12:25 ` Lukasz Majewski
2014-05-07 12:57 ` [U-Boot] [PATCH v3] lib:crc32:hash: " Lukasz Majewski
2014-05-07 23:04 ` Simon Glass
2014-05-08 8:59 ` Lukasz Majewski
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=20140505174730.B1E413809DA@gemini.denx.de \
--to=wd@denx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox