Not entirely sure why the DVB core code has its own crc32 table -- not only
should it be using the one the kernel provides, but AFAICT nothing in the
tree actually seem to _use_ its dvb_set_crc32() function anyway.
I'm assuming the latter is just a symptom of a partial merge and some
driver not yet in the tree is going to use it... this patch fixes the
former.
===== lib/Makefile 1.15 vs edited =====
--- 1.15/lib/Makefile Wed Oct 30 01:19:29 2002
+++ edited/lib/Makefile Fri Nov 8 10:56:03 2002
@@ -27,6 +27,7 @@
obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/
obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/
+include $(TOPDIR)/drivers/media/dvb/dvb-core/Makefile.lib
include $(TOPDIR)/drivers/net/Makefile.lib
include $(TOPDIR)/drivers/usb/class/Makefile.lib
include $(TOPDIR)/fs/Makefile.lib
===== drivers/media/dvb/dvb-core/dvb_demux.c 1.1 vs edited =====
--- 1.1/drivers/media/dvb/dvb-core/dvb_demux.c Tue Oct 22 15:48:37 2002
+++ edited/drivers/media/dvb/dvb-core/dvb_demux.c Fri Nov 8 10:57:24 2002
@@ -24,6 +24,7 @@
#include <linux/vmalloc.h>
#include <linux/module.h>
#include <linux/poll.h>
+#include <linux/crc32.h>
#include <linux/version.h>
#include <asm/uaccess.h>
@@ -108,68 +109,11 @@
return 184;
}
-
-static u32
-dvb_crc_table[256] = {
- 0x00000000, 0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b,
- 0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6, 0x2b4bcb61,
- 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd, 0x4c11db70, 0x48d0c6c7,
- 0x4593e01e, 0x4152fda9, 0x5f15adac, 0x5bd4b01b, 0x569796c2, 0x52568b75,
- 0x6a1936c8, 0x6ed82b7f, 0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3,
- 0x709f7b7a, 0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
- 0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58, 0xbaea46ef,
- 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033, 0xa4ad16ea, 0xa06c0b5d,
- 0xd4326d90, 0xd0f37027, 0xddb056fe, 0xd9714b49, 0xc7361b4c, 0xc3f706fb,
- 0xceb42022, 0xca753d95, 0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1,
- 0xe13ef6f4, 0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0,
- 0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5, 0x2ac12072,
- 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16, 0x018aeb13, 0x054bf6a4,
- 0x0808d07d, 0x0cc9cdca, 0x7897ab07, 0x7c56b6b0, 0x71159069, 0x75d48dde,
- 0x6b93dddb, 0x6f52c06c, 0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08,
- 0x571d7dd1, 0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,
- 0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b, 0xbb60adfc,
- 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698, 0x832f1041, 0x87ee0df6,
- 0x99a95df3, 0x9d684044, 0x902b669d, 0x94ea7b2a, 0xe0b41de7, 0xe4750050,
- 0xe9362689, 0xedf73b3e, 0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2,
- 0xc6bcf05f, 0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34,
- 0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80, 0x644fc637,
- 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb, 0x4f040d56, 0x4bc510e1,
- 0x46863638, 0x42472b8f, 0x5c007b8a, 0x58c1663d, 0x558240e4, 0x51435d53,
- 0x251d3b9e, 0x21dc2629, 0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5,
- 0x3f9b762c, 0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,
- 0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e, 0xf5ee4bb9,
- 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65, 0xeba91bbc, 0xef68060b,
- 0xd727bbb6, 0xd3e6a601, 0xdea580d8, 0xda649d6f, 0xc423cd6a, 0xc0e2d0dd,
- 0xcda1f604, 0xc960ebb3, 0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7,
- 0xae3afba2, 0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71,
- 0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74, 0x857130c3,
- 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640, 0x4e8ee645, 0x4a4ffbf2,
- 0x470cdd2b, 0x43cdc09c, 0x7b827d21, 0x7f436096, 0x7200464f, 0x76c15bf8,
- 0x68860bfd, 0x6c47164a, 0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e,
- 0x18197087, 0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,
- 0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d, 0x2056cd3a,
- 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce, 0xcc2b1d17, 0xc8ea00a0,
- 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb, 0xdbee767c, 0xe3a1cbc1, 0xe760d676,
- 0xea23f0af, 0xeee2ed18, 0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4,
- 0x89b8fd09, 0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662,
- 0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf, 0xa2f33668,
- 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4};
-
-u32 dvb_crc32(u8 *data, int len)
-{
- int i;
- u32 crc = 0xffffffff;
-
- for (i=0; i<len; i++)
- crc = (crc << 8) ^ dvb_crc_table[((crc >> 24) ^ *data++) & 0xff];
- return crc;
-}
-
void dvb_set_crc32(u8 *data, int length)
{
u32 crc;
- crc=dvb_crc32(data,length);
+ crc=crc32_le(~0, data, length);
data[length] = (crc>>24)&0xff;
data[length+1] = (crc>>16)&0xff;
data[length+2] = (crc>>8)&0xff;
--- /dev/null Sat Aug 31 00:31:37 2002
+++ edited/drivers/media/dvb/dvb-core/Makefile.lib Fri Nov 8 10:55:14 2002
@@ -0,0 +1 @@
+obj-$(CONFIG_DVB_CORE) += crc32.o
--
dwmw2
David Woodhouse wrote:
> Not entirely sure why the DVB core code has its own crc32 table -- not only
> should it be using the one the kernel provides, but AFAICT nothing in the
> tree actually seem to _use_ its dvb_set_crc32() function anyway.
the crc32 table was defined because the same driver works for 2.4
kernels, there we need our own crc32 implementation. I'll check if we
can use the generic code in the kernel and then move the dvb_crc32 code
into the 2.4 compatibility file compat.c
That the crc32 check is currently not called by the software
demultiplexer is a known bug, it's already fixed in local CVS and will
get into the kernel with the next patchset. I'm currently preparing this
patchset but want to test it a little more.
Alan: do you have doubts or is there a reason not to apply the last
patchset I sent you on Tue, 29 Oct 2002? (well - it was kind of huge,
but all the namespace fixes and cleanups should justify the patch's
size, not?)
Holger
[email protected] said:
> the crc32 table was defined because the same driver works for 2.4
> kernels, there we need our own crc32 implementation.
JFFS2 in 2.4 has the same problem. The fix is to backport the 2.5 crc32
code so that 2.4 isn't gratuitously different. That patch has been sent to
Alan already, I believe it's going to be sent to Marcelo for 2.4.21-pre1.
--
dwmw2
Hi David,
I'm looking on the generic crc32 code right now, but need some time to
completely understand the code. Have you checked that this code
implements the same generator polynomial as defined in the DVB standard?
Holger
[email protected] said:
> I'm looking on the generic crc32 code right now, but need some time
> to completely understand the code. Have you checked that this code
> implements the same generator polynomial as defined in the DVB
> standard?
sort of...
--
dwmw2
On Fri, 2002-11-08 at 13:57, Holger Waechtler wrote:
> Alan: do you have doubts or is there a reason not to apply the last
> patchset I sent you on Tue, 29 Oct 2002? (well - it was kind of huge,
> but all the namespace fixes and cleanups should justify the patch's
> size, not?)
I've just been rather busy thats all