summaryrefslogtreecommitdiff
path: root/arch/m68k/kernel/m68k_ksyms.c
AgeCommit message (Collapse)Author
2016-08-07m68k: move exports to definitionsAl Viro
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-12-24m68k: handle presence of 64bit mul/div instructions cleanlyGreg Ungerer
The traditional 68000 processors and the newer reduced instruction set ColdFire processors do not support the 32*32->64 multiply or the 64/32->32 divide instructions. This is not a difference based on the presence of a hardware MMU or not. Create a new config symbol to mark that a CPU type doesn't support the longer multiply/divide instructions. Use this then as a basis for using the fast 64bit based divide (in div64.h) and for linking in the extra libgcc functions that may be required (mulsi3, divsi3, etc). Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-06-14m68k: use kernel processor defines for conditional optimizationsGreg Ungerer
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>
2011-05-24m68k: merge non-mmu and mmu versions of m68k_ksyms.cGreg Ungerer
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>
2011-03-25m68k: merge m68k and m68knommu arch directoriesGreg Ungerer
There is a lot of common code that could be shared between the m68k and m68knommu arch branches. It makes sense to merge the two branches into a single directory structure so that we can more easily share that common code. This is a brute force merge, based on a script from Stephen King <sfking@fdwdc.com>, which was originally written by Arnd Bergmann <arnd@arndb.de>. > The script was inspired by the script Sam Ravnborg used to merge the > includes from m68knommu. For those files common to both arches but > differing in content, the m68k version of the file is renamed to > <file>_mm.<ext> and the m68knommu version of the file is moved into the > corresponding m68k directory and renamed <file>_no.<ext> and a small > wrapper file <file>.<ext> is used to select between the two version. Files > that are common to both but don't differ are removed from the m68knommu > tree and files and directories that are unique to the m68knommu tree are > moved to the m68k tree. Finally, the arch/m68knommu tree is removed. > > To select between the the versions of the files, the wrapper uses > > #ifdef CONFIG_MMU > #include <file>_mm.<ext> > #else > #include <file>_no.<ext> > #endif On top of this file merge I have done a simplistic merge of m68k and m68knommu Kconfig, which primarily attempts to keep existing options and menus in place. Other than a handful of options being moved it produces identical .config outputs on m68k and m68knommu targets I tested it on. With this in place there is now quite a bit of scope for merge cleanups in future patches. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2008-04-17Generic semaphore implementationMatthew Wilcox
Semaphores are no longer performance-critical, so a generic C implementation is better for maintainability, debuggability and extensibility. Thanks to Peter Zijlstra for fixing the lockdep warning. Thanks to Harvey Harrison for pointing out that the unlikely() was unnecessary. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Acked-by: Ingo Molnar <mingo@elte.hu>
2006-10-11[PATCH] clean m68k ksymsAl Viro
sun3_ksyms gone, m68k_ksyms trimmed down to exports of the assembler ones, for sun3 added the missing exports of __ioremap() and iounmap(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-06[PATCH] m68k: cleanup string functionsRoman Zippel
- cleanup asm of string functions - deinline strncat()/strncmp() - provide non-inlined strcpy() Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-25[PATCH] m68k: convert generic irq code to irq controllerRoman Zippel
Convert the generic irq code to use irq controller, this gets rid of the machine specific callbacks and gives better control over irq handling without duplicating lots of code. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] No arch-specific strpbrk implementationsKyle McMartin
While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't being exported from lib/string.c. Investigating further, I noticed a changeset that removed its export and added it to _ksyms.c on a few more architectures. The justification was that "other arches do it." I think this is wrong, since no architecture currently defines __HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it themselves. Therefore, consolidate the export to lib/string.c. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31[PATCH] unexport get_wchanAdrian Bunk
The only user of get_wchan is the proc fs - and proc can't be built modular. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-10[PATCH] dump_thread() cleanupakpm@osdl.org
) From: Adrian Bunk <bunk@stusta.de> - create one common dump_thread() prototype in kernel.h - dump_thread() is only used in fs/binfmt_aout.c and can therefore be removed on all architectures where CONFIG_BINFMT_AOUT is not available Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05[PATCH] m68k: cleanup inline mem functionsRoman Zippel
Use the builtin functions for memset/memclr/memcpy, special optimizations for page operations have dedicated functions now. Uninline memmove/memchr and move all functions into a single file and clean it up a little. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
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!