Commit Graph

24 Commits

Author SHA1 Message Date
Linus Torvalds 84d69848c9 Merge branch 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
Pull kbuild updates from Michal Marek:

 - EXPORT_SYMBOL for asm source by Al Viro.

   This does bring a regression, because genksyms no longer generates
   checksums for these symbols (CONFIG_MODVERSIONS). Nick Piggin is
   working on a patch to fix this.

   Plus, we are talking about functions like strcpy(), which rarely
   change prototypes.

 - Fixes for PPC fallout of the above by Stephen Rothwell and Nick
   Piggin

 - fixdep speedup by Alexey Dobriyan.

 - preparatory work by Nick Piggin to allow architectures to build with
   -ffunction-sections, -fdata-sections and --gc-sections

 - CONFIG_THIN_ARCHIVES support by Stephen Rothwell

 - fix for filenames with colons in the initramfs source by me.

* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: (22 commits)
  initramfs: Escape colons in depfile
  ppc: there is no clear_pages to export
  powerpc/64: whitelist unresolved modversions CRCs
  kbuild: -ffunction-sections fix for archs with conflicting sections
  kbuild: add arch specific post-link Makefile
  kbuild: allow archs to select link dead code/data elimination
  kbuild: allow architectures to use thin archives instead of ld -r
  kbuild: Regenerate genksyms lexer
  kbuild: genksyms fix for typeof handling
  fixdep: faster CONFIG_ search
  ia64: move exports to definitions
  sparc32: debride memcpy.S a bit
  [sparc] unify 32bit and 64bit string.h
  sparc: move exports to definitions
  ppc: move exports to definitions
  arm: move exports to definitions
  s390: move exports to definitions
  m68k: move exports to definitions
  alpha: move exports to actual definitions
  x86: move exports to actual definitions
  ...
2016-10-14 14:26:58 -07:00
Greg Ungerer aa5ac789bd m68k: generalize uboot command line support
The uboot command line support needs to be used by both MMU and no-MMU
setups, but currently we only have the code in the no-MMU code paths.
Move the uboot command line processing code into its own file. Add
appropriate calls to it from both the MMU and no-MMU arch setup code.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2016-09-26 12:02:59 +10:00
Al Viro d13ffb5630 m68k: move exports to definitions
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-08-07 23:47:19 -04:00
Finn Thain 7913ad1ad8 m68k: Multi-platform EARLY_PRINTK
Make the boot console available to more m68k platforms by leveraging
the head.S debug console.

The boot console is enabled by the "earlyprintk" command line argument
which is how most other architectures do this.

This is a change of behaviour for the Mac but does not negatively impact
the common use-case which is not debugging.

This is also a change of behaviour for other platforms because it means
the serial port stays quiet when CONFIG_EARLY_PRINTK is not enabled. This
is also an improvement for the common use-case.

Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Stephen N Chivers <schivers@csc.com.au>
[Geert: CONSOLE_DEBUG should depend on CONFIG_FONT_SUPPORT]
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2014-05-28 10:10:04 +02:00
Geert Uytterhoeven 7bc1e4d8d5 m68k: Add support to export bootinfo in procfs
Add optional support to export the bootinfo used to boot the kernel in a
"bootinfo" file in procfs.  This is useful with kexec.

This is based on the similar feature for ATAGS on ARM.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2013-12-08 11:01:48 +01:00
Geert Uytterhoeven 7d5f5fa276 m68k: Add kexec support
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2013-12-08 11:01:47 +01:00
Geert Uytterhoeven 561839598e m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA
In two places, we check !CONFIG_MMU_SUN3 while we should check
CONFIG_HAS_DMA instead.
While fixing this, the check in <asm/dma-mapping.h> became redundant
(<linux/dma-mapping.h> already handles this case), so just remove it.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2013-02-09 14:23:36 +01:00
Greg Ungerer e93a6bbeb5 m68k: common PCI support definitions and code
Basic set of definitions and support code required to turn on CONFIG_PCI
for the m68k architecture. Nothing specific to any PCI implementation in
any m68k class CPU hardware yet.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2012-07-17 15:49:41 +10:00
Thomas Gleixner ab5fc1ffb9 m68k: Use generic init_task
Same code. Use the generic version.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: http://lkml.kernel.org/r/20120503085034.816195285@linutronix.de
2012-05-05 13:00:23 +02:00
Greg Ungerer 3f0060b0e8 m68k: do not use m68k startup or interrupt code for ColdFire CPUs
The ColdFire CPUs have their own startup and interrupt code (in the
platform/coldfire directory), and do not use the general m68k startup and
interrupt code. In fact the use of the arch/m68k/kernel/head.o is not about
CONFIG_MMU or not, it is really about the machine type we are compiling for.

Modify the selection and use of head.o to be based on the machine type.
Only select the local ints.o and vectors.o code if we are using the classic
68k CPU types (that use the conventional Morotola MMU or SUN3 MMU).

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
2011-12-30 10:20:48 +10:00
Greg Ungerer 409ee2455c m68k: merge the init_task code for mmu and non-mmu targets
The init_task code can be the same for both mmu and non-mmu targets.
None of the alignment carried out in the the current init_task code
is necessary. The linker script takes care of aligning the init_thread
structure to a THREAD SIZE boundary, and that is all we need.

So use the init_task.c code for all target types, that makes m68k
code consistent with what most other architectures do.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-12-24 21:47:56 +10:00
Geert Uytterhoeven d890d73995 m68k/irq: Remove obsolete m68k irq framework
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-11-08 22:35:52 +01:00
Geert Uytterhoeven 4936f63cb7 m68k/irq: Add genirq support
Disabled on all platforms for now

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
[v1] Acked-by: Thomas Gleixner <tglx@linutronix.de>
2011-11-08 22:35:49 +01:00
Greg Ungerer bc4f4ac2f0 m68k: move hardware vector setting from traps.c to its own file
Most of the trap.c code is general to all m68k arch members. But the code
it currently contains to set the hardware vector table is quite specific to
the 680x0 family. They can have the vector table at any address unlike
other family members (which either support only a single fixed address,
or a limited range of addresses). So lets move that code out to a new file,
vectors.c. This will make sharing the rest of the trap.c code easier and
cleaner.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-10-18 14:22:25 +10:00
Greg Ungerer 0a01b310fe m68k: merge the mmu and non-mmu kernel/Makefiles
The few differences between the mmu and non-mmu kernel/Makefiles can
easily be handled inside of a single Makefile. Merge the 2 back into
a single Makefile.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2011-10-18 14:22:25 +10:00
Greg Ungerer 66d857b08b m68k: merge m68k and m68knommu arch directories
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>
2011-03-25 14:05:13 +10:00
Adrian Bunk 2171a19a24 m68k: remove the dead PCI code
This patch removes the no longer used m68k PCI code.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-14 10:23:27 -07:00
Mathieu Desnoyers a0c14d28df Stringify support commas
> This is a no-no for those archs that still use -traditional.
 > > I dunno if this is a problem for you at the moment and the
 > > right fix is anyway to nuke -traditional.
 > >
 > >     Sam

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-20 17:24:38 -07:00
Matthew Wilcox 64ac24e738 Generic semaphore implementation
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>
2008-04-17 10:42:34 -04:00
Roman Zippel fbe9c96129 m68k: runtime patching infrastructure
Add the basic infrastructure to allow runtime patching of kernel and modules
to optimize a few functions with parameters, which are only calculated once
during bootup and are otherwise constant.  Use this for the conversion between
virtual and physical addresses.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-31 07:58:13 -07:00
Al Viro 5ea8176994 [PATCH] sort the devres mess out
* Split the implementation-agnostic stuff in separate files.
* Make sure that targets using non-default request_irq() pull
  kernel/irq/devres.o
* Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive;
  allow architectures to turn them off (we needed these symbols anyway for
  dependencies of quite a few drivers).
* protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-11 11:18:07 -08:00
Al Viro 58ba81dba7 [PATCH] m68k/kernel/dma.c assumes !MMU_SUN3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-08 18:50:58 -07:00
Roman Zippel b035c96b2d [PATCH] m68k: Add the generic dma API functions
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-25 10:00:56 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00