1. 30 8月, 2014 1 次提交
  2. 09 8月, 2014 1 次提交
    • V
      kexec: load and relocate purgatory at kernel load time · 12db5562
      Vivek Goyal 提交于
      Load purgatory code in RAM and relocate it based on the location.
      Relocation code has been inspired by module relocation code and purgatory
      relocation code in kexec-tools.
      
      Also compute the checksums of loaded kexec segments and store them in
      purgatory.
      
      Arch independent code provides this functionality so that arch dependent
      bootloaders can make use of it.
      
      Helper functions are provided to get/set symbol values in purgatory which
      are used by bootloaders later to set things like stack and entry point of
      second kernel etc.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      12db5562
  3. 08 4月, 2014 1 次提交
  4. 06 3月, 2014 1 次提交
  5. 08 12月, 2013 2 次提交
  6. 24 10月, 2013 1 次提交
  7. 13 9月, 2013 1 次提交
  8. 26 8月, 2013 1 次提交
    • G
      m68knommu: user generic iomap to support ioread*/iowrite* · f79b8592
      Greg Ungerer 提交于
      There is no reason we cannot use the generic iomap support to give us
      the ioread* and iowrite* family of IO access functions. The m68k arch with
      MMU enabled does, so this makes us consistent for all m68k now.
      
      Some potentially valid drivers will fail to compile without these,
      for example:
      
      drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of
      function ‘iowrite8’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of
      function ‘iowrite16’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:91:2: error: implicit declaration of
      function ‘iowrite32’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:96:2: error: implicit declaration of
      function ‘ioread8’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:101:2: error: implicit declaration of
      function ‘ioread16’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:106:2: error: implicit declaration of
      function ‘ioread32’ [-Werror=implicit-function-declaration]
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      f79b8592
  9. 17 4月, 2013 1 次提交
  10. 16 4月, 2013 1 次提交
  11. 08 4月, 2013 1 次提交
  12. 13 3月, 2013 1 次提交
  13. 28 2月, 2013 1 次提交
  14. 14 2月, 2013 1 次提交
    • A
      burying unused conditionals · d64008a8
      Al Viro 提交于
      __ARCH_WANT_SYS_RT_SIGACTION,
      __ARCH_WANT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_SCHED_RR_GET_INTERVAL - not used anymore
      CONFIG_GENERIC_{SIGALTSTACK,COMPAT_RT_SIG{ACTION,QUEUEINFO,PENDING,PROCMASK}} -
      can be assumed always set.
      d64008a8
  15. 04 2月, 2013 3 次提交
  16. 20 12月, 2012 1 次提交
  17. 17 10月, 2012 1 次提交
  18. 09 10月, 2012 2 次提交
  19. 01 10月, 2012 1 次提交
  20. 28 9月, 2012 1 次提交
    • D
      Make most arch asm/module.h files use asm-generic/module.h · 786d35d4
      David Howells 提交于
      Use the mapping of Elf_[SPE]hdr, Elf_Addr, Elf_Sym, Elf_Dyn, Elf_Rel/Rela,
      ELF_R_TYPE() and ELF_R_SYM() to either the 32-bit version or the 64-bit version
      into asm-generic/module.h for all arches bar MIPS.
      
      Also, use the generic definition mod_arch_specific where possible.
      
      To this end, I've defined three new config bools:
      
       (*) HAVE_MOD_ARCH_SPECIFIC
      
           Arches define this if they don't want to use the empty generic
           mod_arch_specific struct.
      
       (*) MODULES_USE_ELF_RELA
      
           Arches define this if their modules can contain RELA records.  This causes
           the Elf_Rela mapping to be emitted and allows apply_relocate_add() to be
           defined by the arch rather than have the core emit an error message.
      
       (*) MODULES_USE_ELF_REL
      
           Arches define this if their modules can contain REL records.  This causes
           the Elf_Rel mapping to be emitted and allows apply_relocate() to be
           defined by the arch rather than have the core emit an error message.
      
      Note that it is possible to allow both REL and RELA records: m68k and mips are
      two arches that do this.
      
      With this, some arch asm/module.h files can be deleted entirely and replaced
      with a generic-y marker in the arch Kbuild file.
      
      Additionally, I have removed the bits from m32r and score that handle the
      unsupported type of relocation record as that's now handled centrally.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      786d35d4
  21. 17 8月, 2012 1 次提交
  22. 31 7月, 2012 1 次提交
  23. 10 6月, 2012 2 次提交
  24. 06 6月, 2012 1 次提交
  25. 22 5月, 2012 1 次提交
    • T
      timers: Fixup the Kconfig consolidation fallout · 764e0da1
      Thomas Gleixner 提交于
      Sigh, I missed to check which architecture Kconfig files actually
      include the core Kconfig file. There are a few which did not. So we
      broke them.
      
      Instead of adding the includes to those, we are better off to move the
      include to init/Kconfig like we did already with irqs and others.
      
      This does not change anything for the architectures using the old
      style periodic timer mode. It just solves the build wreckage there.
      
      For those architectures which use the clock events infrastructure it
      moves the include of the core Kconfig file to "General setup" which is
      a way more logical place than having it at random locations specified
      by the architecture specific Kconfigs.
      Reported-by: NIngo Molnar <mingo@kernel.org>
      Cc: Anna-Maria Gleixner <anna-maria@glx-um.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      764e0da1
  26. 21 5月, 2012 1 次提交
  27. 05 5月, 2012 2 次提交
  28. 05 3月, 2012 2 次提交
    • G
      m68k: make support for FPU hardware configurable · 9657a872
      Greg Ungerer 提交于
      The classic m68k code has always supported an FPU (although it may have
      been a software emulated one). The non-MMU m68k code has never supported FPU
      hardware. To help in merging common code create a configation setting that
      signifies if we are builing in FPU support or not.
      
      This switch, CONFIG_FPU, is set as per the current use cases. So it is
      always enabled if CONFIG_MMU is set, and disabled otherwise. With a little
      extra code it will be possible to disable it on the classic m68k platforms
      as well, and to enable it on non-MMU platforms that do have hardware FPU.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      9657a872
    • G
      m68knommu: remove unused CONFIG_GENERIC_CMOS_UPDATE option · b6c58e8a
      Greg Ungerer 提交于
      The CONFIG_GENERIC_CMOS_UPDATE switch is always enabled for the non-MMU
      m68k case. But the underlying code to support it, update_persistent_clock(),
      doesn't end up doing anything on the currently supported non-MMU platforms.
      No platforms supply the necessary function support for writing back the RTC.
      
      So lets remove this option and support code. This also brings m68knommu
      in line with the m68k, which doesn't enabled this switch either.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      b6c58e8a
  29. 12 1月, 2012 1 次提交
  30. 30 12月, 2011 3 次提交
  31. 24 12月, 2011 1 次提交
    • G
      m68k: handle presence of 64bit mul/div instructions cleanly · 84f3fb7a
      Greg 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: NGreg Ungerer <gerg@uclinux.org>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      84f3fb7a