linux - Linux Kernel (branches are rebased on master from time to time)

Age	Commit message (Collapse)	Author	Files	Lines
2007-03-07	[MIPS] Export __copy_user_inatomic.	Ralf Baechle	1	-0/+1
	Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2007-01-08	[MIPS] csum_partial and copy in parallel	Atsushi Nemoto	1	-0/+2
	Implement optimized asm version of csum_partial_copy_nocheck, csum_partial_copy_from_user and csum_and_copy_to_user which can do calculate and copy in parallel, based on memcpy.S. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-06-30	Remove obsolete #include <linux/config.h>	Jörn Engel	1	-1/+0
	Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-04-19	[MIPS] Sort out duplicate exports.	Ralf Baechle	1	-15/+0
	Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-11	[PATCH] No arch-specific strpbrk implementations	Kyle McMartin	1	-1/+0
	While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't being exported from lib/string.c. Investigating further, I noticed a changeset that removed its export and added it to _ksyms.c on a few more architectures. The justification was that "other arches do it." I think this is wrong, since no architecture currently defines __HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it themselves. Therefore, consolidate the export to lib/string.c. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05	[PATCH] mips: clean up 32/64-bit configuration	Ralf Baechle	1	-1/+1
	Start cleaning 32-bit vs. 64-bit configuration. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16	Linux-2.6.12-rc2v2.6.12-rc2	Linus Torvalds	1	-0/+67
	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!