linux - linux

	Commit message (Collapse)	Author	Age	Files	Lines
*	[MIPS] fixmap: delete unused __set_fixmap, set_fixmap and set_fixmap_nocache	Ralf Baechle	2008-01-29	1	-10/+0
\| \| \| \|	Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
*	[MIPS] Fix "no space between function name and open parenthesis" warnings.	Ralf Baechle	2007-10-12	1	-2/+2
\| \| \| \|	Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
*	[MIPS] Fix aliasing bug in copy_to_user_page / copy_from_user_page	Ralf Baechle	2006-10-22	1	-3/+11
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	The current implementation uses a sequence of a cacheflush and a copy. This is racy in case of a multithreaded debuggee and renders GDB virtually unusable. Aside this fixes a performance hog rendering access to /proc/cmdline very slow and resulting in a enough cache stalls for the 34K AP/SP programming model to make the bare metal code on the non-Linux VPE miss RT deadlines. The main part of this patch was originally written by Ralf Baechle; Atushi Nemoto did the the debugging. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
*	[MIPS] Fix FIXADDR_TOP for TX39/TX49.	Atsushi Nemoto	2006-06-29	1	-0/+4
\| \| \| \| \| \| \| \| \| \| \|	FIXADDR_TOP is used for HIGHMEM and for upper limit of vmalloc area on 32bit kernel. TX39XX and TX49XX have "reserved" segment in CKSEG3 area. 0xff000000-0xff3fffff on TX49XX and 0xff000000-0xfffeffff on TX39XX are reserved (unmapped, uncached) therefore can not be used as mapped area. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
*	Don't include linux/config.h from anywhere else in include/	David Woodhouse	2006-04-26	1	-1/+0
\| \| \| \|	Signed-off-by: David Woodhouse <dwmw2@infradead.org>
*	Delete duplicate copy of fixrange_init.	Ralf Baechle	2005-10-29	1	-0/+7
\| \| \| \|	Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
*	Linux-2.6.12-rc2v2.6.12-rc2	Linus Torvalds	2005-04-17	1	-0/+110
	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!