1. 16 5月, 2015 1 次提交
  2. 12 5月, 2015 1 次提交
  3. 30 3月, 2015 1 次提交
    • A
      ARM: 8323/1: force linker to use PIC veneers · 02e541db
      Ard Biesheuvel 提交于
      When building a very large kernel, it is up to the linker to decide
      when and where to insert stubs to allow calls to functions that are
      out of range for the ordinary b/bl instructions.
      
      However, since the kernel is built as a position dependent binary,
      these stubs (aka veneers) may contain absolute addresses, which will
      break far calls performed with the MMU off.
      
      For instance, the call from __enable_mmu() in the .head.text section
      to __turn_mmu_on() in the .idmap.text section may be turned into
      something like this:
      
      c0008168 <__enable_mmu>:
      c0008168:       f020 0002       bic.w   r0, r0, #2
      c000816c:       f420 5080       bic.w   r0, r0, #4096
      c0008170:       f000 b846       b.w     c0008200 <____turn_mmu_on_veneer>
      [...]
      c0008200 <____turn_mmu_on_veneer>:
      c0008200:       4778            bx      pc
      c0008202:       46c0            nop
      c0008204:       e59fc000        ldr     ip, [pc]
      c0008208:       e12fff1c        bx      ip
      c000820c:       c13dfae1        teqgt   sp, r1, ror #21
      [...]
      c13dfae0 <__turn_mmu_on>:
      c13dfae0:       4600            mov     r0, r0
      [...]
      
      After adding --pic-veneer to the LDFLAGS, the veneer is emitted like
      this instead:
      
      c0008200 <____turn_mmu_on_veneer>:
      c0008200:       4778            bx      pc
      c0008202:       46c0            nop
      c0008204:       e59fc004        ldr     ip, [pc, #4]
      c0008208:       e08fc00c        add     ip, pc, ip
      c000820c:       e12fff1c        bx      ip
      c0008210:       013d7d31        teqeq   sp, r1, lsr sp
      c0008214:       00000000        andeq   r0, r0, r0
      
      Note that this particular example is best addressed by moving
      .head.text and .idmap.text closer together, but this issue could
      potentially affect any code that needs to execute with the
      MMU off.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      02e541db
  4. 28 3月, 2015 2 次提交
  5. 16 3月, 2015 1 次提交
  6. 11 3月, 2015 1 次提交
  7. 09 1月, 2015 1 次提交
    • W
      ARM: probes: move all probe code to dedicate directory · fca08f32
      Wang Nan 提交于
      In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
      King suggests to move all probe related code to arch/arm/probes. This
      patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
      patch also moves patch.h to 'arch/arm/include/asm/patch.h', and related
      '#include' directives are also midified to '#include <asm/patch.h>'.
      
      Following is an overview of this patch:
      
       ./arch/arm/kernel/               ./arch/arm/probes/
       |-- Makefile                     |-- Makefile
       |-- probes-arm.c          ==>    |-- decode-arm.c
       |-- probes-arm.h          ==>    |-- decode-arm.h
       |-- probes-thumb.c        ==>    |-- decode-thumb.c
       |-- probes-thumb.h        ==>    |-- decode-thumb.h
       |-- probes.c              ==>    |-- decode.c
       |-- probes.h              ==>    |-- decode.h
       |                                |-- kprobes
       |                                |   |-- Makefile
       |-- kprobes-arm.c         ==>    |   |-- actions-arm.c
       |-- kprobes-common.c      ==>    |   |-- actions-common.c
       |-- kprobes-thumb.c       ==>    |   |-- actions-thumb.c
       |-- kprobes.c             ==>    |   |-- core.c
       |-- kprobes.h             ==>    |   |-- core.h
       |-- kprobes-test-arm.c    ==>    |   |-- test-arm.c
       |-- kprobes-test.c        ==>    |   |-- test-core.c
       |-- kprobes-test.h        ==>    |   |-- test-core.h
       |-- kprobes-test-thumb.c  ==>    |   `-- test-thumb.c
       |                                `-- uprobes
       |                                    |-- Makefile
       |-- uprobes-arm.c         ==>        |-- actions-arm.c
       |-- uprobes.c             ==>        |-- core.c
       |-- uprobes.h             ==>        `-- core.h
       |
       `-- patch.h               ==>    arch/arm/include/asm/patch.h
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NJon Medhurst <tixy@linaro.org>
      fca08f32
  8. 22 10月, 2014 3 次提交
  9. 02 10月, 2014 1 次提交
  10. 26 9月, 2014 1 次提交
  11. 25 9月, 2014 1 次提交
  12. 31 7月, 2014 1 次提交
  13. 22 7月, 2014 1 次提交
  14. 19 7月, 2014 1 次提交
  15. 18 7月, 2014 1 次提交
  16. 14 7月, 2014 1 次提交
  17. 13 7月, 2014 1 次提交
  18. 08 7月, 2014 1 次提交
  19. 24 5月, 2014 1 次提交
  20. 25 2月, 2014 1 次提交
  21. 20 2月, 2014 2 次提交
    • J
      kbuild: dtbs_install: new make target · f4d4ffc0
      Jason Cooper 提交于
      Unlike other build products in the Linux kernel, there is no 'make
      *install' mechanism to put devicetree blobs in a standard place.
      
      This commit adds a new 'dtbs_install' make target which copies all of
      the dtbs into the INSTALL_DTBS_PATH directory. INSTALL_DTBS_PATH can be
      set before calling make to change the default install directory. If not
      set then it defaults to:
      
      	$INSTALL_PATH/dtbs/$KERNELRELEASE.
      
      This is done to keep dtbs from different kernel versions separate until
      things have settled down.  Once the dtbs are stable, and not so strongly
      linked to the kernel version, the devicetree files will most likely move
      to their own repo.  Users will need to upgrade install scripts at that
      time.
      
      v7: (reworked by Grant Likely)
      - Moved rules from arch/arm/Makefile to arch/arm/boot/dts/Makefile so
        that each dtb install could have a separate target and be reported as
        part of the make output.
      - Fixed dependency problem to ensure $KERNELRELEASE is calculated before
        attempting to install
      - Removed option to call external script. Copying the files should be
        sufficient and a build system can post-process the install directory.
        Despite the fact an external script is used for installing the kernel,
        I don't think that is a pattern that should be encouraged. I would
        rather see buildroot type tools post process the install directory to
        rename or move dtb files after installing to a staging directory.
        - Plus it is easy to add a hook after the fact without blocking the
          rest of this feature.
      - Move the helper targets into scripts/Makefile.lib with the rest of the
        common dtb rules
      Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rob Herring <robh+dt@kernel.org>
      f4d4ffc0
    • R
      ARM: virt: make mach-virt just a kconfig option · 05e2a3de
      Rob Herring 提交于
      The mach code for mach-virt is no longer needed, so we can remove all of
      mach-virt except the kconfig entry.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      05e2a3de
  22. 07 2月, 2014 1 次提交
  23. 29 1月, 2014 1 次提交
  24. 23 12月, 2013 1 次提交
  25. 21 12月, 2013 1 次提交
  26. 20 12月, 2013 1 次提交
    • K
      stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures · 19952a92
      Kees Cook 提交于
      Instead of duplicating the CC_STACKPROTECTOR Kconfig and
      Makefile logic in each architecture, switch to using
      HAVE_CC_STACKPROTECTOR and keep everything in one place. This
      retains the x86-specific bug verification scripts.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-arch@vger.kernel.org
      Link: http://lkml.kernel.org/r/1387481759-14535-2-git-send-email-keescook@chromium.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      19952a92
  27. 18 12月, 2013 1 次提交
  28. 17 12月, 2013 1 次提交
  29. 14 12月, 2013 1 次提交
  30. 13 12月, 2013 1 次提交
  31. 10 12月, 2013 1 次提交
  32. 20 10月, 2013 1 次提交
  33. 03 10月, 2013 1 次提交
    • R
      arm, kbuild: make "make install" not depend on vmlinux · 19514fc6
      Robert Richter 提交于
      Install targets (install, zinstall, uinstall) on arm have a dependency
      to vmlinux. This may cause parts of the kernel to be rebuilt during
      installation. We must avoid this since this may run as root. Install
      targets "ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE." as Linus
      emphasized this in:
      
       http://lkml.org/lkml/2013/7/10/600
      
      So on arm and maybe other archs we need the same as for x86:
      
       1648e4f8 x86, kbuild: make "make install" not depend on vmlinux
      
      This patch fixes this for arm. Dependencies are removed and instead a
      check to install.sh is added for the files that are needed.
      
      This issue was uncovered by this build error where the -j option is
      used in conjunction with install targets:
      
       $ make <makeflags>
       $ make <makeflags> zinstall
       ...
         DEPMOD
       Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease>
      
      (INSTALL_MOD_PATH and INSTALL_PATH variables set, so no root perms
      required in this case.)
      
      The problem is that zinstall on arm due to its dependency to vmlinux
      does a prepare/prepare3 and finally does a forced rewrite of
      kernel.release even if it exists already.
      
      Rebuilding kernel.release removes it first and then recreates it. This
      might race with another parallel make job running depmod.
      
      So this patch should fix this one too.
      
      Also quoting $(KERNELRELEASE) arg for install.sh as this messes
      argument order in case it is empty (which is the case if the kernel
      was not built yet).
      Signed-off-by: NRobert Richter <robert.richter@linaro.org>
      Signed-off-by: NRobert Richter <rric@kernel.org>
      Acked-by: Michal Marek <mmarek@suse.cz>.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      19514fc6
  34. 17 9月, 2013 1 次提交
    • L
      ARM: delete mach-shark · 136dfa5e
      Linus Walleij 提交于
      The Shark machine sub-architecture (also known as DNARD, the
      DIGITAL Network Appliance Reference Design) lacks a maintainer
      able to apply and test patches to modernize the architecture.
      
      It is suspected that the current kernel, while it compiles,
      does not even boot on this machine. The listed maintainer has
      expressed that he will not be able to spend any time on the
      maintenance for the coming year.
      
      So let's delete it from the kernel for now. It can always be
      resurrected with git revert if maintenance is resumed.
      
      As the VIA82c505 PCI adapter was only used by this
      architecture, that gets deleted too.
      
      Cc: arm@kernel.org
      Cc: Alexander Schulz <alex@shark-linux.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      136dfa5e
  35. 27 7月, 2013 1 次提交
  36. 23 7月, 2013 1 次提交