Commit e1b5bb6d12 ("consolidate cond_syscall
and SYSCALL_ALIAS declarations") broke the h8300 build because it removed
the duplicate SYMBOL_NAME() macro from arch/h8300/include/asm/linkage.h,
and all the h8300 asm files include <asm/linkage.h> instead of
<linux/linkage.h>:
arch/h8300/kernel/entry.S: Assembler messages:
arch/h8300/kernel/entry.S:158: Error: junk at end of line, first unrecognized character is `('
...
arch/h8300/kernel/syscalls.S: Assembler messages:
arch/h8300/kernel/syscalls.S:6: Error: junk at end of line, first unrecognized character is `('
...
arch/h8300/lib/abs.S: Assembler messages:
arch/h8300/lib/abs.S:12: Error: junk at end of line, first unrecognized character is `('
...
arch/h8300/lib/memcpy.S: Assembler messages:
arch/h8300/lib/memcpy.S:13: Error: junk at end of line, first unrecognized character is `('
...
arch/h8300/lib/memset.S: Assembler messages:
arch/h8300/lib/memset.S:13: Error: junk at end of line, first unrecognized character is `('
...
Commit 126de6b20b ("linkage.h: fix build
breakage due to symbol prefix handling") broke it even more, by removing
SYMBOL_NAME() and replacing it by __SYMBOL_NAME().
Commit f8ce1faf55 ("Merge tag
'modules-next-for-linus' of
git://git.kernel.org/pub/scm/linuxkernel/git/rusty/linux")
also removed __SYMBOL_NAME(), hidden in a merge conflict resolution.
Hence, replace the use of SYMBOL_NAME() and SYMBOL_NAME_LABEL() in h8300
assembler sources by hardcoding the underscore symbol prefix, like other
architectures (blackfin/metag) do.
This allows to kill SYMBOL_NAME_LABEL(). Now <asm/linkage.h> becomes empty,
and h8300 can be switched to asm-generic/linkage.h.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
The current h8300 GPIO implementation doesn't provide the standard GPIO
API, and in fact provides only direction control rather than normal GPIO
functionality. Currently this is only used by the platform interrupt
implementation rather than by a range of drivers so in preparation for
moving over to gpiolib move the header out of the way of the gpiolib
header, allowing a default GPIO implementation to be provided.
For actual use of these GPIOs with gpiolib a real driver would still need
to be written but there appears to be no current need for this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT,
PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining
arch_has_single_step in <asm/ptrace.h> and implementing the
user_enable_single_step and user_disable_single_step functions, which also
causes the breakpoint information to be cleared on fork, which could be
considered a bug fix.
Also the TIF_SYSCALL_TRACE thread flag is now cleared on PTRACE_KILL which
it previously wasn't which is consistent with all architectures using the
modern ptrace code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ICC likes to complain about storage class not being first, GCC doesn't
care much (except for cases like "inline static").
have a hard time seeing how it could break anything.
Thanks to Gabriel A. Devenyi for pointing out
http://linuxicc.sourceforge.net/ which is what made me create this patch.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Assignment doesn't make much sense here as condition would always be true.
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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!
