1. 21 11月, 2013 1 次提交
  2. 11 10月, 2013 3 次提交
  3. 21 8月, 2013 3 次提交
  4. 14 8月, 2013 1 次提交
  5. 08 8月, 2013 1 次提交
  6. 10 1月, 2013 4 次提交
    • A
      powerpc: Avoid load of static chain register when calling nested functions... · 98679fb0
      Anton Blanchard 提交于
      powerpc: Avoid load of static chain register when calling nested functions through a pointer on 64bit
      
      The ppc64 ABI has a static chain register (r11) which is only used
      when calling nested functions through a pointer. Considering that
      we take a dim view of nested functions in the kernel, we have a lot
      of unnecessary overhead here.
      
      gcc 4.7 has an option to disable loading of r11 so lets use it.
      
      If hell freezes over and hipsters manage to litter the kernel
      with nested functions, gcc will give us an error message and
      won't simply compile bad code:
      
          You cannot take the address of a nested function if you use
          the -mno-pointers-to-nested-functions option.
      
      Furthermore our kernel module trampolines don't setup the static
      chain register so adding this option and forcing gcc to error out
      makes even more sense.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      98679fb0
    • A
      powerpc: Build kernel with -mcmodel=medium · 1fbe9cf2
      Anton Blanchard 提交于
      Finally remove the two level TOC and build with -mcmodel=medium.
      
      Unfortunately we can't build modules with -mcmodel=medium due to
      the tricks the kernel module loader plays with percpu data:
      
      # -mcmodel=medium breaks modules because it uses 32bit offsets from
      # the TOC pointer to create pointers where possible. Pointers into the
      # percpu data area are created by this method.
      #
      # The kernel module loader relocates the percpu data section from the
      # original location (starting with 0xd...) to somewhere in the base
      # kernel percpu data space (starting with 0xc...). We need a full
      # 64bit relocation for this to work, hence -mcmodel=large.
      
      On older kernels we fall back to the two level TOC (-mminimal-toc)
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1fbe9cf2
    • A
      powerpc: Relocate prom_init.c on 64bit · 5ac47f7a
      Anton Blanchard 提交于
      The ppc64 kernel can get loaded at any address which means
      our very early init code in prom_init.c must be relocatable. We do
      this with a pretty nasty RELOC() macro that we wrap accesses of
      variables with. It is very fragile and sometimes we forget to add a
      RELOC() to an uncommon path or sometimes a compiler change breaks it.
      
      32bit has a much more elegant solution where we build prom_init.c
      with -mrelocatable and then process the relocations manually.
      Unfortunately we can't do the equivalent on 64bit and we would
      have to build the entire kernel relocatable (-pie), resulting in a
      large increase in kernel footprint (megabytes of relocation data).
      The relocation data will be marked __initdata but it still creates
      more pressure on our already tight memory layout at boot.
      
      Alan Modra pointed out that the 64bit ABI is relocatable even
      if we don't build with -pie, we just need to relocate the TOC.
      This patch implements that idea and relocates the TOC entries of
      prom_init.c. An added bonus is there are very few relocations to
      process which helps keep boot times on simulators down.
      
      gcc does not put 64bit integer constants into the TOC but to be
      safe we may want a build time script which passes through the
      prom_init.c TOC entries to make sure everything looks reasonable.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5ac47f7a
    • M
      powerpc: Add a powerpc implementation of SHA-1 · 323a6bf1
      Michael Ellerman 提交于
      This patch adds a crypto driver which provides a powerpc accelerated
      implementation of SHA-1, accelerated in that it is written in asm.
      
      Original patch by Paul, minor fixups for upstream by moi.
      
      Lightly tested on 64-bit with the test program here:
      
       http://michael.ellerman.id.au/files/junkcode/sha1test.c
      
      Seems to work, and is "not slower" than the generic version.
      
      Needs testing on 32-bit.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      323a6bf1
  7. 15 11月, 2012 1 次提交
    • M
      powerpc: dtc is required to build dtb files · 8662d0bc
      Matthew McClintock 提交于
      Fixes this following:
      
      $ make distclean; make corenet32_smp_defconfig; make p4080ds.dtb
        CLEAN   arch/powerpc/boot
        CLEAN   scripts/basic
        CLEAN   scripts/dtc
        CLEAN   scripts/genksyms
        CLEAN   scripts/kconfig
        CLEAN   scripts/mod
        CLEAN   scripts
        CLEAN   include/config include/generated
        CLEAN   .config
        HOSTCC  scripts/basic/fixdep
        HOSTCC  scripts/kconfig/conf.o
        SHIPPED scripts/kconfig/zconf.tab.c
        SHIPPED scripts/kconfig/zconf.lex.c
        SHIPPED scripts/kconfig/zconf.hash.c
        HOSTCC  scripts/kconfig/zconf.tab.o
        HOSTLD  scripts/kconfig/conf
      scripts/kconfig/conf --silentoldconfig Kconfig
        DTC     arch/powerpc/boot/p4080ds.dtb
      /bin/sh: /local/home/mattsm/git/linux/scripts/dtc/dtc: No such file or directory
      make[1]: *** [arch/powerpc/boot/p4080ds.dtb] Error 1
      make: *** [p4080ds.dtb] Error 2
      Signed-off-by: NMatthew McClintock <msm@freescale.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8662d0bc
  8. 27 6月, 2012 1 次提交
  9. 16 5月, 2012 1 次提交
  10. 30 4月, 2012 3 次提交
  11. 23 2月, 2012 1 次提交
  12. 20 12月, 2011 1 次提交
    • S
      powerpc: Process dynamic relocations for kernel · 9c5f7d39
      Suzuki Poulose 提交于
      The following patch implements the dynamic relocation processing for
      PPC32 kernel. relocate() accepts the target virtual address and relocates
       the kernel image to the same.
      
      Currently the following relocation types are handled :
      
      	R_PPC_RELATIVE
      	R_PPC_ADDR16_LO
      	R_PPC_ADDR16_HI
      	R_PPC_ADDR16_HA
      
      The last 3 relocations in the above list depends on value of Symbol indexed
      whose index is encoded in the Relocation entry. Hence we need the Symbol
      Table for processing such relocations.
      
      Note: The GNU ld for ppc32 produces buggy relocations for relocation types
      that depend on symbols. The value of the symbols with STB_LOCAL scope
      should be assumed to be zero. - Alan Modra
      Signed-off-by: NSuzuki K. Poulose <suzuki@in.ibm.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Alan Modra <amodra@au1.ibm.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
      Signed-off-by: NJosh Boyer <jwboyer@gmail.com>
      9c5f7d39
  13. 08 12月, 2011 1 次提交
    • B
      powerpc: Add support for OpenBlockS 600 · 11eab297
      Benjamin Herrenschmidt 提交于
      So I've had one of these for a while and it looks like the vendor never
      bothered submitting the support upstream.
      
      This adds it using ppc40x_simple and provides a device-tree.
      
      There are some changes to the boot wrapper because the way u-boot works
      on this thing, it seems to expect a multipart image with the kernel,
      initrd and dtb in it.
      
      The USB support is missing as it needs the yet unmerged driver for
      the DWC OTG part and the GPIOs may need further definition in the dts.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      11eab297
  14. 28 11月, 2011 1 次提交
  15. 17 11月, 2011 1 次提交
    • K
      powerpc: Remove buggy 9-year-old test for binutils < 2.12.1 · a9a8f77a
      Kyle Moffett 提交于
      Recent binutils refuses to assemble AltiVec opcodes when in e500/SPE
      mode, as some of those opcodes alias the "SPE" instructions.  This
      triggers an ancient binutils version check even when building a kernel
      with CONFIG_ALTIVEC disabled.
      
      In theory, the check could be conditionalized on CONFIG_ALTIVEC, but in
      practice it has long outlived its utility.  It is virtually impossible
      to find binutils older than 2.12.1 (released 2002) in the wild anymore.
      Even ancient RedHat Enterprise Linux 4 has binutils-2.14.
      
      To fix the kernel build when done natively on e500 systems with this new
      binutils, the test is simply removed.
      Signed-off-by: NKyle Moffett <Kyle.D.Moffett@boeing.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a9a8f77a
  16. 22 7月, 2011 1 次提交
    • M
      net: filter: BPF 'JIT' compiler for PPC64 · 0ca87f05
      Matt Evans 提交于
      An implementation of a code generator for BPF programs to speed up packet
      filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
      
      Filter code is generated as an ABI-compliant function in module_alloc()'d mem
      with stackframe & prologue/epilogue generated if required (simple filters don't
      need anything more than an li/blr).  The filter's local variables, M[], live in
      registers.  Supports all BPF opcodes, although "complicated" loads from negative
      packet offsets (e.g. SKF_LL_OFF) are not yet supported.
      
      There are a couple of further optimisations left for future work; many-pass
      assembly with branch-reach reduction and a register allocator to push M[]
      variables into volatile registers would improve the code quality further.
      
      This currently supports big-endian 64-bit PowerPC only (but is fairly simple
      to port to PPC32 or LE!).
      
      Enabled in the same way as x86-64:
      
      	echo 1 > /proc/sys/net/core/bpf_jit_enable
      
      Or, enabled with extra debug output:
      
      	echo 2 > /proc/sys/net/core/bpf_jit_enable
      Signed-off-by: NMatt Evans <matt@ozlabs.org>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ca87f05
  17. 01 7月, 2011 1 次提交
  18. 24 8月, 2010 1 次提交
  19. 09 8月, 2010 1 次提交
  20. 03 8月, 2010 1 次提交
    • S
      kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line · 6588169d
      Sam Ravnborg 提交于
      It is now possible to assign options to AS, CC and LD
      on the command line - which is only used when building modules.
      
      {A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
      in the arch makefiles, thus users had no way to specify
      additional options to AS, CC, LD when building modules
      without overriding the original value.
      
      Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
      that is used by arch specific files and free up
      {A,C,LD}FLAGS_MODULE so they can be assigned on
      the command line.
      
      All arch Makefiles that used the old variables has been updated.
      
      Note: Previously we had a MODFLAGS variable for both
      AS and CC. But in favour of consistency this was dropped.
      So in some cases arch Makefile has one assignmnet replaced by
      two assignmnets.
      
      Note2: MODFLAGS was not documented and is dropped
      without any notice. I do not expect much/any breakage
      from this.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Denys Vlasenko <vda.linux@googlemail.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Chen Liqin <liqin.chen@sunplusct.com>
      Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
      Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      6588169d
  21. 08 7月, 2010 1 次提交
  22. 06 2月, 2010 1 次提交
  23. 24 9月, 2009 1 次提交
    • T
      powerpc: Check for unsupported relocs when using CONFIG_RELOCATABLE · 144ef909
      Tony Breeds 提交于
      When using CONFIG_RELOCATABLE, we build the kernel as a position
      independent executable. The kernel then uses a little bit of relocation
      code to relocate itself. That code only deals with R_PPC64_RELATIVE
      relocations though. If for some reason you use assembly constructs
      such as LOAD_REG_IMMEDIATE() to load the address of a symbol, you'll
      generate different kinds of relocations that won't be processed properly
      and bad things will happen. (We have 2 such bugs today).
      
      The perl script tries to filter out "known" bad ones. It's possible
      that we are missing some in the case of a weak function that nobody
      implements, we'll see if we get false positive and fix it.
      Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      144ef909
  24. 20 9月, 2009 2 次提交
    • S
      arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0 · 51b563fc
      Sam Ravnborg 提交于
      Albin Tonnerre <albin.tonnerre@free-electrons.com> reported:
      
          Bash 4 filters out variables which contain a dot in them.
          This happends to be the case of CPPFLAGS_vmlinux.lds.
          This is rather unfortunate, as it now causes
          build failures when using SHELL=/bin/bash to compile,
          or when bash happens to be used by make (eg when it's /bin/sh)
      
      Remove the common definition of CPPFLAGS_vmlinux.lds by
      pushing relevant stuff to either Makefile.build or the
      arch specific kernel/Makefile where we build the linker script.
      
      This is also nice cleanup as we move the information out where
      it is used.
      
      Notes for the different architectures touched:
      
      arm - we use an already exported symbol
      cris - we use a config symbol aleady available
             [Not build tested]
      mips - the jiffies complexity has moved to vmlinux.lds.S where we need it.
             Added a few variables to CPPFLAGS - they are only used by
             the linker script.
             [Not build tested]
      powerpc - removed assignment that is not needed
                [not build tested]
      sparc - simplified it using $(BITS)
      um - introduced a few new exported variables to deal with this
      xtensa - added options to CPP invocation
               [not build tested]
      
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      51b563fc
    • S
      kbuild: use INSTALLKERNEL to select customized installkernel script · caa27b66
      Sam Ravnborg 提交于
      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:
      
        0f8e2d62
        ("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: NPeter 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: NSam Ravnborg <sam@ravnborg.org>
      caa27b66
  25. 20 8月, 2009 1 次提交
  26. 09 6月, 2009 1 次提交
  27. 11 3月, 2009 1 次提交
  28. 03 12月, 2008 1 次提交
  29. 21 10月, 2008 1 次提交
  30. 16 9月, 2008 1 次提交