[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4638FFB2.4000609@redhat.com>
Date: Wed, 02 May 2007 17:16:34 -0400
From: Kristian Høgsberg <krh@...hat.com>
To: Pekka Enberg <penberg@...helsinki.fi>
CC: Stefan Richter <stefanr@...6.in-berlin.de>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux1394-devel <linux1394-devel@...ts.sourceforge.net>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 1/6] firewire: handling of cards, buses, nodes
Pekka Enberg wrote:
> On 5/2/07, Stefan Richter <stefanr@...6.in-berlin.de> wrote:
>> +/* The lib/crc16.c implementation uses the standard (0x8005)
>> + * polynomial, but we need the ITU-T (or CCITT) polynomial (0x1021).
>> + * The implementation below works on an array of host-endian u32
>> + * words, assuming they'll be transmited msb first. */
>> +u16
>> +crc16_itu_t(const u32 *buffer, size_t length)
>> +{
>
> [snip]
>
> So put it in lib/crc-itu-t.c? Btw, there's apparently another ITU-T
> implementation floating around by Ivo van Doorn.
I looked into this a while back, and the kernel does have a CCITT based crc16
function. The problem is that it works on the opposite bit order from what I
need, so to use it I'll have to bitswap every byte as it goes in and then
bitswap the resulting crc16. That's more code and probably less efficient
than just implementing the crc itself. I wouldn't mind moving it to lib/
though, but nobody else in the kernel is using this bit order.
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists