linux-toradex.git/arch/m68k/kernel, branch v3.0.58 Linux kernel for Apalis and Colibri modules m68k: Make sys_atomic_cmpxchg_32 work on classic m68k 2012-08-09T15:27:53+00:00 Andreas Schwab schwab@linux-m68k.org 2012-07-27T22:20:34+00:00 d3be3eeedbc5b39f93b27c6ece2879c1d417eed5 commit 9e2760d18b3cf179534bbc27692c84879c61b97c upstream. User space access must always go through uaccess accessors, since on classic m68k user space and kernel space are completely separate. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Tested-by: Thorsten Glaser <tg@debian.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9e2760d18b3cf179534bbc27692c84879c61b97c upstream.

User space access must always go through uaccess accessors, since on
classic m68k user space and kernel space are completely separate.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Tested-by: Thorsten Glaser <tg@debian.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
m68k: use kernel processor defines for conditional optimizations 2011-06-14T01:42:29+00:00 Greg Ungerer gerg@uclinux.org 2011-06-02T06:07:33+00:00 734c3ce3bd4d51c932893b9f6d32b9ded31acdff Older m68k-linux compilers will include pre-defined symbols that confuse what processor it is being targeted for. For example gcc-4.1.2 will pre-define __mc68020__ even if you specify the target processor as -m68000 on the gcc command line. Newer versions of gcc have this corrected. In a few places the m68k code uses defined(__mc68020__) for optimizations that include instructions that are specific to the CPU 68020 and above. When compiling with older compilers this will be true even when we have selected to compile for the older 68000 processors. Switch to using the kernel processor defines, CONFIG_M68020 and friends. Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
Older m68k-linux compilers will include pre-defined symbols that
confuse what processor it is being targeted for. For example gcc-4.1.2
will pre-define __mc68020__ even if you specify the target processor
as -m68000 on the gcc command line. Newer versions of gcc have this
corrected.

In a few places the m68k code uses defined(__mc68020__) for optimizations
that include instructions that are specific to the CPU 68020 and above.
When compiling with older compilers this will be true even when we have
selected to compile for the older 68000 processors.

Switch to using the kernel processor defines, CONFIG_M68020 and friends.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
m68knommu: fix linker script exported name sections 2011-06-14T01:42:29+00:00 Greg Ungerer gerg@uclinux.org 2011-06-02T04:09:32+00:00 dab104a73694b06fe4a162cb39d678716da62a67 The recent commit titled "module: Sort exported symbols" (f02e8a65) changed the exported symbol name sections. Bring the m68knommu linker script into line with those changes - including the sorting of the symbol names. Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
The recent commit titled "module: Sort exported symbols" (f02e8a65)
changed the exported symbol name sections. Bring the m68knommu linker
script into line with those changes - including the sorting of the
symbol names.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
ns: Wire up the setns system call 2011-05-28T17:48:39+00:00 Eric W. Biederman ebiederm@xmission.com 2011-05-28T02:28:27+00:00 7b21fddd087678a70ad64afc0f632e0f1071b092 32bit and 64bit on x86 are tested and working. The rest I have looked at closely and I can't find any problems. setns is an easy system call to wire up. It just takes two ints so I don't expect any weird architecture porting problems. While doing this I have noticed that we have some architectures that are very slow to get new system calls. cris seems to be the slowest where the last system calls wired up were preadv and pwritev. avr32 is weird in that recvmmsg was wired up but never declared in unistd.h. frv is behind with perf_event_open being the last syscall wired up. On h8300 the last system call wired up was epoll_wait. On m32r the last system call wired up was fallocate. mn10300 has recvmmsg as the last system call wired up. The rest seem to at least have syncfs wired up which was new in the 2.6.39. v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com> v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com> v4: Moved wiring up of the system call to another patch v5: ported to v2.6.39-rc6 v6: rebased onto parisc-next and net-next to avoid syscall conflicts. v7: ported to Linus's latest post 2.6.39 tree. >  arch/blackfin/include/asm/unistd.h     |    3 ++- >  arch/blackfin/mach-common/entry.S      |    1 + Acked-by: Mike Frysinger <vapier@gentoo.org> Oh - ia64 wiring looks good. Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
32bit and 64bit on x86 are tested and working.  The rest I have looked
at closely and I can't find any problems.

setns is an easy system call to wire up.  It just takes two ints so I
don't expect any weird architecture porting problems.

While doing this I have noticed that we have some architectures that are
very slow to get new system calls.  cris seems to be the slowest where
the last system calls wired up were preadv and pwritev.  avr32 is weird
in that recvmmsg was wired up but never declared in unistd.h.  frv is
behind with perf_event_open being the last syscall wired up.  On h8300
the last system call wired up was epoll_wait.  On m32r the last system
call wired up was fallocate.  mn10300 has recvmmsg as the last system
call wired up.  The rest seem to at least have syncfs wired up which was
new in the 2.6.39.

v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
v4: Moved wiring up of the system call to another patch
v5: ported to v2.6.39-rc6
v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
v7: ported to Linus's latest post 2.6.39 tree.

>  arch/blackfin/include/asm/unistd.h     |    3 ++-
>  arch/blackfin/mach-common/entry.S      |    1 +
Acked-by: Mike Frysinger <vapier@gentoo.org>

Oh - ia64 wiring looks good.
Acked-by: Tony Luck <tony.luck@intel.com>

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
m68knommu: Use generic show_interrupts() 2011-05-24T05:17:23+00:00 Geert Uytterhoeven geert@linux-m68k.org 2011-04-30T21:15:07+00:00 531d2895917566ab0d82faa0696d0576569f1053 Apart from whitespace differences, /proc/interrupts doesn't change by enabling GENERIC_IRQ_SHOW. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
Apart from whitespace differences, /proc/interrupts doesn't change by
enabling GENERIC_IRQ_SHOW.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
m68k: merge the mmu and non-mmu versions of sys_m68k.c 2011-05-24T05:17:21+00:00 Greg Ungerer gerg@uclinux.org 2011-04-21T02:48:07+00:00 cae2e6cc002d6fdee7d8a230736fa7c685e54b35 There is a lot of common code in the sys_m68k.c files. The mmu and non-mmu versions can easily be merged into a single file. There is really only 2 functions that differ in the 2 cases. A single ifdef on CONFIG_MMU can take care of this. Alternatively we could break those 2 functions out and maintain sys_m68k_no.c and sys_m68k_mm.c with just this code in it (Makefile could then just build the right one). Does anyone have strong feelings on which way they want this done? Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
There is a lot of common code in the sys_m68k.c files. The mmu and non-mmu
versions can easily be merged into a single file.

There is really only 2 functions that differ in the 2 cases. A single
ifdef on CONFIG_MMU can take care of this. Alternatively we could break
those 2 functions out and maintain sys_m68k_no.c and sys_m68k_mm.c with
just this code in it (Makefile could then just build the right one).
Does anyone have strong feelings on which way they want this done?

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
m68knommu: Remove obsolete #include <linux/sys.h> 2011-05-24T05:17:19+00:00 Geert Uytterhoeven geert@linux-m68k.org 2011-04-06T19:43:19+00:00 b60de9f5142ffc677e4e1bf0d1e8ad177d21095f Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
m68k: merge mmu and non-mmu versions of asm-offsets.c 2011-05-24T05:17:18+00:00 Greg Ungerer gerg@uclinux.org 2011-03-29T05:55:36+00:00 aa4d1f897f6a7ffdb3654a2152b60d9d832951a3 It is strait forward to merge the mmu and non-mmu versions of asm-offstes.c. Some name changes are required for the preempt and thread_info.flags in the non-mmu entry.S assembler to make them consistent for both setups. Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
It is strait forward to merge the mmu and non-mmu versions of
asm-offstes.c. Some name changes are required for the preempt and
thread_info.flags in the non-mmu entry.S assembler to make them
consistent for both setups.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
m68k: merge non-mmu and mmu versions of m68k_ksyms.c 2011-05-24T00:03:51+00:00 Greg Ungerer gerg@uclinux.org 2011-03-29T05:06:37+00:00 a697dc934f52355494b746d7b5568227e0910ae8 After cleaning up m68k_ksyms_no.c it is now strait forward to merge the non-mmu and mmu versions of m68k_ksyms.c. The need for the extra gcc functions is not strictly based on having an MMU or not. It is based on the family the processor belongs too, so use an appropriate conditional check. Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
After cleaning up m68k_ksyms_no.c it is now strait forward to merge
the non-mmu and mmu versions of m68k_ksyms.c. The need for the extra
gcc functions is not strictly based on having an MMU or not. It is
based on the family the processor belongs too, so use an appropriate
conditional check.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
m68knommu: remove un-needed exporting of COLDFIRE symbols 2011-05-24T00:03:51+00:00 Greg Ungerer gerg@uclinux.org 2011-03-29T04:25:14+00:00 2c7f3feb63276f08dd289a2cb29694af17ad70dd There is no reason most of the symbols enclosed in a conditional on CONFIG_COLDFIRE need to be exported. And they sure don't need to be doing it in m68k_ksyms_no.c. Move the dma symbols export (which are currently needed) to the definitions of those, and remove the rest of the exporting here. Signed-off-by: Greg Ungerer <gerg@uclinux.org> 
There is no reason most of the symbols enclosed in a conditional
on CONFIG_COLDFIRE need to be exported. And they sure don't need to
be doing it in m68k_ksyms_no.c. Move the dma symbols export (which
are currently needed) to the definitions of those, and remove the
rest of the exporting here.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>