Commit graph

10 commits

Author SHA1 Message Date
Linus Torvalds
a44f99c7ef Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6
* 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6: (25 commits)
  video: change to new flag variable
  scsi: change to new flag variable
  rtc: change to new flag variable
  rapidio: change to new flag variable
  pps: change to new flag variable
  net: change to new flag variable
  misc: change to new flag variable
  message: change to new flag variable
  memstick: change to new flag variable
  isdn: change to new flag variable
  ieee802154: change to new flag variable
  ide: change to new flag variable
  hwmon: change to new flag variable
  dma: change to new flag variable
  char: change to new flag variable
  fs: change to new flag variable
  xtensa: change to new flag variable
  um: change to new flag variables
  s390: change to new flag variable
  mips: change to new flag variable
  ...

Fix up trivial conflict in drivers/hwmon/Makefile
2011-03-20 18:14:55 -07:00
matt mooney
c73028a028 s390: change to new flag variable
Replace EXTRA_CFLAGS with ccflags-y.

Signed-off-by: matt mooney <mfm@muteddisk.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2011-03-17 14:02:57 +01:00
Heiko Carstens
d7b081ac0b [S390] support XZ compressed kernel
Add support for XZ compressed kernel. Same as on x86 and sh.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-03-15 17:08:24 +01:00
Martin Schwidefsky
a8c8d7c683 [S390] correct ipl parameter block safe guard
The 'output' variable is passed from decompress_kernel to
check_ipl_parmblock before it is initialized. That disables the
safe guard against the overwrite of the ipl parameter block.
Fix this by passing the correct value to check_ipl_parmblock.

Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-02-17 13:13:59 +01:00
Heiko Carstens
cdf566498d [S390] Add support for LZO-compressed kernels.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2010-05-26 23:27:10 +02:00
Martin Schwidefsky
06c0dd72ae [S390] fix boot failures with compressed kernels
Fix two bugs with the kernel image compression:
1) reset the bss section of the compressed vmlinux
2) clear the high half of the registers for 64 bit early enough
   for the decompression step

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2010-03-24 11:49:54 +01:00
Martin Schwidefsky
1844c9bc0b [S390] add support for compressed kernels
Add the "bzImage" compile target and the necessary code  to generate
compressed kernel images. The old style uncompressed "image" target
is preserved, a simple make will build them both.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2010-02-26 22:37:33 +01:00
Sam Ravnborg
caa27b66bd kbuild: use INSTALLKERNEL to select customized installkernel script
Replace the use of CROSS_COMPILE to select a customized
installkernel script with the possibility to set INSTALLKERNEL
to select a custom installkernel script when running make:

    make INSTALLKERNEL=arm-installkernel install

With this patch we are now more consistent across
different architectures - they did not all support use
of CROSS_COMPILE.

The use of CROSS_COMPILE was a hack as this really belongs
to gcc/binutils and the installkernel script does not change
just because we change toolchain.

The use of CROSS_COMPILE caused troubles with an upcoming patch
that saves CROSS_COMPILE when a kernel is built - it would no
longer be installable.
[Thanks to Peter Z. for this hint]

This patch undos what Ian did in commit:

  0f8e2d62fa
  ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")

The patch has been lightly tested on x86 only - but all changes
looks obvious.

Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Russell King <linux@arm.linux.org.uk> [arm]
Acked-by: Paul Mundt <lethal@linux-sh.org> [sh]
Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86]
Cc: Ian Campbell <icampbell@arcom.com>
Cc: Tony Luck <tony.luck@intel.com> [ia64]
Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64]
Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r]
Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc]
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc]
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390]
Cc: Thomas Gleixner <tglx@linutronix.de> [x86]
Cc: Ingo Molnar <mingo@redhat.com> [x86]
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2009-09-20 12:18:14 +02:00
Ian Campbell
0f8e2d62fa [PATCH] use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh
The attached patch causes the various arch specific install.sh scripts to
look for ${CROSS_COMPILE}installkernel rather than just installkernel (in
both /sbin/ and ~/bin/ where the script already did this).  This allows you
to have e.g.  arm-linux-installkernel as a handy way to install on your
cross target.  It also prevents the script picking up on the host
/sbin/installkernel which causes the script to fall through and do the
install itself (which is what I actually use myself, with $INSTALL_PATH
set).

I don't believe it causes back-compatibility problems since calling the
host installkernel was never likely to work or be what you wanted when
cross compiling anyway.  If $CROSS_COMPILE isn't set then nothing changes.

I only use ARM and i386 myself but I figured it couldn't hurt to do the
whole lot.  I've cc'd those who I hope are the arch maintainers for files
that I've touched.

Signed-off-by: Ian Campbell <icampbell@arcom.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 09:45:07 -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