linux-toradex.git/include/linux/byteorder/generic.h, branch v2.6.18-rc7 Linux kernel for Apalis and Colibri modules [PATCH] remove gcc-2 checks 2006-01-09T04:14:02+00:00 Andrew Morton akpm@osdl.org 2006-01-08T09:04:09+00:00 a1365647022eb05a5993f270a78e9bef3bf554eb Remove various things which were checking for gcc-1.x and gcc-2.x compilers. From: Adrian Bunk <bunk@stusta.de> Some documentation updates and removes some code paths for gcc < 3.2. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Remove various things which were checking for gcc-1.x and gcc-2.x compilers.

From: Adrian Bunk <bunk@stusta.de>

    Some documentation updates and removes some code paths for gcc < 3.2.

Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[BYTEORDER]: Document alignment and byteorder macros 2005-09-20T02:57:36+00:00 Ed L. Cashin ecashin@coraid.com 2005-09-20T02:57:36+00:00 e0487992ce1dd7ae7da9c6aabdb19570bb95432b This patch comments the fact that although passing le64_to_cpup et al. is within the intended use of the byteorder macros, using get_unaligned is the recommended way to go. Signed-off-by: Ed L. Cashin <ecashin@coraid.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
This patch comments the fact that although passing le64_to_cpup et
al. is within the intended use of the byteorder macros, using
get_unaligned is the recommended way to go.

Signed-off-by: Ed L. Cashin <ecashin@coraid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 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! 
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!