linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2013-11-03	lib: crc32: add functionality to combine two crc32{, c}s in GF(2)	Daniel Borkmann	1	-0/+40
	This patch adds a combinator to merge two or more crc32{,c}s into a new one. This is useful for checksum computations of fragmented skbs that use crc32/crc32c as checksums. The arithmetics for combining both in the GF(2) was taken and slightly modified from zlib. Only passing two crcs is insufficient as two crcs and the length of the second piece is needed for merging. The code is made generic, so that only polynomials need to be passed for crc32_le resp. crc32c_le. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2012-03-23	crc32: bolt on crc32c	Darrick J. Wong	1	-0/+2
	Reuse the existing crc32 code to stamp out a crc32c implementation. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Bob Pearson <rpearson@systemfabricworks.com> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22	crc32: add missed brackets in macro	Konstantin Khlebnikov	1	-1/+1
	Add brackets around typecasted argument in crc32() macro. Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-12-08	[PATCH] crc32: replace bitreverse by bitrev32	Akinobu Mita	1	-2/+2
	This patch replaces bitreverse() by bitrev32. The only users of bitreverse() are crc32 itself and via-velocity. Cc: Jeff Garzik <jgarzik@pobox.com> Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+27
	Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!