linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2008-08-13	[h8300] move include/asm-h8300 to arch/h8300/include/asm	Linus Torvalds	1	-140/+0
	Done as a script (well, a single "git mv" actually) on request from Yoshinori Sato as a way to avoid a huge diff. Requested-by: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08	aout: move STACK_TOP[_MAX] to asm/processor.h	David Howells	1	-0/+5
	Move STACK_TOP[_MAX] out of asm/a.out.h and into asm/processor.h as they're required whether or not A.OUT format is available. Signed-off-by: David Howells <dhowells@redhat.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-06-01	h8300 trival patches	Yoshinori Sato	1	-1/+1
	- warning fix. - call trace area check fix. - There is no meaning, ' & ' it deletes Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-07-12	[PATCH] Make cpu_relax() imply barrier() on all arches	Chase Venters	1	-1/+2
	During the recent discussion of taking 'volatile' off of the spinlock, I noticed that while most arches #define cpu_relax() such that it implies barrier(), some arches define cpu_relax() to be empty. This patch changes the definition of cpu_relax() for frv, h8300, m68knommu, sh, sh64, v850 and xtensa from an empty while(0) to the compiler barrier(). Signed-off-by: Chase Venters <chase.venters@clientec.com> Acked-by: Arjan van de Ven <arjan@Linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-26	Don't include linux/config.h from anywhere else in include/	David Woodhouse	1	-1/+0
	Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+135
	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!