linux-toradex.git/include/asm-arm/mmu_context.h, branch v2.6.16.11 Linux kernel for Apalis and Colibri modules [ARM] Add linux/compiler.h includes where required 2005-11-16T17:23:57+00:00 Russell King rmk@dyn-67.arm.linux.org.uk 2005-11-16T17:23:57+00:00 8dc39b883e9497445b53c498be7493c3e43af006 atomic.h, bitops.h and mmu_context.h are using likely/unlikely. thread_info.h uses __attribute_const__. Hence these files require linux/compiler.h to be included. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
atomic.h, bitops.h and mmu_context.h are using likely/unlikely.
thread_info.h uses __attribute_const__.  Hence these files require
linux/compiler.h to be included.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Fix second missing declaration of cache_is_vivt() 2005-11-06T19:47:04+00:00 Russell King rmk@dyn-67.arm.linux.org.uk 2005-11-06T19:47:04+00:00 4fe15ba08fdb280536bd7019e8505969c4ac6852 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM SMP] Do not clear cpu_vm_mask for VIPT caches 2005-11-03T20:32:45+00:00 Russell King rmk@dyn-67.arm.linux.org.uk 2005-11-03T20:32:45+00:00 7e5e6e9a509c4ed2973a345ec7ffb96577f42e26 Since we do not invalidate TLBs/caches on MM switches, we should not clear the cpu_vm_mask for the CPU. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Since we do not invalidate TLBs/caches on MM switches, we should not
clear the cpu_vm_mask for the CPU.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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!