summaryrefslogtreecommitdiff
path: root/include/asm-m68knommu/processor.h
AgeCommit message (Collapse)AuthorFilesLines
2006-10-04fix file specification in commentsUwe Zeisberger1-1/+1
Many files include the filename at the beginning, serveral used a wrong one. Signed-off-by: Uwe Zeisberger <Uwe_Zeisberger@digi.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-07-12[PATCH] Make cpu_relax() imply barrier() on all archesChase Venters1-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-06-26[PATCH] m68knommu: force stack alignment on ColdFireGreg Ungerer1-8/+20
This patch solve a bug triggered by execvp (this function use calloc to store the argument list and gcc 3.4.x align the stack to word, not to dword). This situation aren't related to signal handling and all 2.6.x have the bug. On ColdFire targets we must force the stack to be aligned. Original patch from Andrea Tarani <andrea.tarani@gilbarco.com>, Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-26Don't include linux/config.h from anywhere else in include/David Woodhouse1-1/+0
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-11-02[PATCH] m68knommu: change use of extern inline to static inline in headersGreg Ungerer1-2/+2
"extern inline" doesn't make much sense here. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+131
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!