1. 13 Jun, 2017 1 commit
  2. 08 Jun, 2017 1 commit
    • Michael Ellerman's avatar
      powerpc/book3s64: Move PPC_DT_CPU_FTRs and enable it by default · c6ee9619
      Michael Ellerman authored
      The PPC_DT_CPU_FTRs is a bit misplaced in menuconfig, it shows up with
      other general kernel options. It's really more at home in the "Platform
      Support" section, so move it there.
      Also enable it by default, for Book3s 64. It does mostly nothing unless
      the device tree properties are found, and we will want it enabled
      eventually in distro kernels, so turn it on to start getting more
      Fixes: 5a61ef74
       ("powerpc/64s: Support new device tree binding for discovering CPU features")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  3. 01 Jun, 2017 1 commit
  4. 09 May, 2017 2 commits
  5. 01 May, 2017 1 commit
  6. 28 Apr, 2017 1 commit
    • Nicholas Piggin's avatar
      powerpc: Add NMI IPI infrastructure · ddd703ca
      Nicholas Piggin authored
      Add a simple NMI IPI system that handles concurrency and reentrancy.
      The platform does not have to implement a true non-maskable interrupt,
      the default is to simply use the debugger break IPI message. This has
      now been co-opted for a general IPI message, and users (debugger and
      crash) have been reimplemented on top of the NMI system.
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      [mpe: Incorporate incremental fixes from Nick]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  7. 26 Apr, 2017 2 commits
  8. 24 Apr, 2017 1 commit
  9. 23 Apr, 2017 1 commit
    • Ingo Molnar's avatar
      Revert "x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation" · 6dd29b3d
      Ingo Molnar authored
      This reverts commit 2947ba05.
      Dan Williams reported dax-pmem kernel warnings with the following signature:
         WARNING: CPU: 8 PID: 245 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0x1f5/0x200
         percpu ref (dax_pmem_percpu_release [dax_pmem]) <= 0 (0) after switching to atomic
      ... and bisected it to this commit, which suggests possible memory corruption
      caused by the x86 fast-GUP conversion.
      He also pointed out:
        This is similar to the backtrace when we were not properly handling
        pud faults and was fixed with this commit: 220ced16
       "mm: fix
        get_user_pages() vs device-dax pud mappings"
        I've found some missing _devmap checks in the generic
        get_user_pages_fast() path, but this does not fix the regression
      So given that there are known bugs, and a pretty robust looking bisection
      points to this commit suggesting that are unknown bugs in the conversion
      as well, revert it for the time being - we'll re-try in v4.13.
      Reported-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: aneesh.kumar@linux.vnet.ibm.com
      Cc: dann.frazier@canonical.com
      Cc: dave.hansen@intel.com
      Cc: steve.capper@linaro.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  10. 21 Apr, 2017 1 commit
    • Michael Ellerman's avatar
      powerpc/mm: Add support for runtime configuration of ASLR limits · 9fea59bd
      Michael Ellerman authored
      Add powerpc support for mmap_rnd_bits and mmap_rnd_compat_bits, which are two
      sysctls that allow a user to configure the number of bits of randomness used for
      Because of the way the Kconfig for ARCH_MMAP_RND_BITS is defined, we have to
      construct at least the MIN value in Kconfig, vs in a header which would be more
      natural. Given that we just go ahead and do it all in Kconfig.
      At least according to the code (the documentation makes no mention of it), the
      value is defined as the number of bits of randomisation *of the page*, not the
      address. This makes some sense, with larger page sizes more of the low bits are
      forced to zero, which would reduce the randomisation if we didn't take the
      PAGE_SIZE into account. However it does mean the min/max values have to change
      depending on the PAGE_SIZE in order to actually limit the amount of address
      space consumed by the randomisation.
      The result of that is that we have to define the default values based on both
      32-bit vs 64-bit, but also the configured PAGE_SIZE. Furthermore now that we
      have 128TB address space support on Book3S, we also have to take that into
      Finally we can wire up the value in arch_mmap_rnd().
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBhupesh Sharma <bhsharma@redhat.com>
      Tested-by: default avatarBhupesh Sharma <bhsharma@redhat.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
  11. 18 Apr, 2017 1 commit
  12. 10 Apr, 2017 1 commit
  13. 06 Apr, 2017 1 commit
  14. 20 Mar, 2017 1 commit
  15. 18 Mar, 2017 1 commit
  16. 06 Mar, 2017 1 commit
    • Michael Ellerman's avatar
      powerpc: Sort the selects under CONFIG_PPC · a7d2475a
      Michael Ellerman authored
      We have a big list of selects under CONFIG_PPC, and currently they're
      completely unsorted. This means people tend to add new selects at the
      bottom of the list, and so two commits which both add a new select will
      often conflict.
      Instead sort it alphabetically. This is nicer in and of itself, but also
      means two commits that add a new select will have a greater chance of
      not conflicting.
      Add a note at the top and bottom asking people to keep it sorted.
      And while we're here pad out the 'if' expressions to make them stand
      Suggested-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  17. 10 Feb, 2017 2 commits
    • Anton Blanchard's avatar
      powerpc/ftrace: Fix confusing help text for DISABLE_MPROFILE_KERNEL · 496e9cb5
      Anton Blanchard authored
      The final paragraph of the help text is reversed. We want to enable
      this option by default, and disable it if the toolchain has a working
      Fixes: 8c50b72a
       ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel")
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    • Anju T's avatar
      powerpc/kprobes: Implement Optprobes · 51c9c084
      Anju T authored
      Current infrastructure of kprobe uses the unconditional trap instruction
      to probe a running kernel. Optprobe allows kprobe to replace the trap
      with a branch instruction to a detour buffer. Detour buffer contains
      instructions to create an in memory pt_regs. Detour buffer also has a
      call to optimized_callback() which in turn call the pre_handler(). After
      the execution of the pre-handler, a call is made for instruction
      emulation. The NIP is determined in advanced through dummy instruction
      emulation and a branch instruction is created to the NIP at the end of
      the trampoline.
      To address the limitation of branch instruction in POWER architecture,
      detour buffer slot is allocated from a reserved area. For the time
      being, 64KB is reserved in memory for this purpose.
      Instructions which can be emulated using analyse_instr() are the
      candidates for optimization. Before optimization ensure that the address
      range between the detour buffer allocated and the instruction being
      probed is within +/- 32MB.
      Signed-off-by: default avatarAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  18. 03 Feb, 2017 2 commits
    • Ard Biesheuvel's avatar
      modversions: treat symbol CRCs as 32 bit quantities · 71810db2
      Ard Biesheuvel authored
      The modversion symbol CRCs are emitted as ELF symbols, which allows us
      to easily populate the kcrctab sections by relying on the linker to
      associate each kcrctab slot with the correct value.
      This has a couple of downsides:
       - Given that the CRCs are treated as memory addresses, we waste 4 bytes
         for each CRC on 64 bit architectures,
       - On architectures that support runtime relocation, a R_<arch>_RELATIVE
         relocation entry is emitted for each CRC value, which identifies it
         as a quantity that requires fixing up based on the actual runtime
         load offset of the kernel. This results in corrupted CRCs unless we
         explicitly undo the fixup (and this is currently being handled in the
         core module code)
       - Such runtime relocation entries take up 24 bytes of __init space
         each, resulting in a x8 overhead in [uncompressed] kernel size for
      Switching to explicit 32 bit values on 64 bit architectures fixes most
      of these issues, given that 32 bit values are not treated as quantities
      that require fixing up based on the actual runtime load offset.  Note
      that on some ELF64 architectures [such as PPC64], these 32-bit values
      are still emitted as [absolute] runtime relocatable quantities, even if
      the value resolves to a build time constant.  Since relative relocations
      are always resolved at build time, this patch enables MODULE_REL_CRCS on
      powerpc when CONFIG_RELOCATABLE=y, which turns the absolute CRC
      references into relative references into .rodata where the actual CRC
      value is stored.
      So redefine all CRC fields and variables as u32, and redefine the
      __CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
      inline assembler (which is necessary since 64-bit C code cannot use
      32-bit types to hold memory addresses, even if they are ultimately
      resolved using values that do not exceed 0xffffffff).  To avoid
      potential problems with legacy 32-bit architectures using legacy
      toolchains, the equivalent C definition of the kcrctab entry is retained
      for 32-bit architectures.
      Note that this mostly reverts commit d4703aef
       ("module: handle ppc64
      relocating kcrctabs when CONFIG_RELOCATABLE=y")
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Andrew Donnellan's avatar
      powerpc: Enable support for GCC plugins · 65c059bc
      Andrew Donnellan authored
      Enable support for GCC plugins on powerpc.
      Add an additional version check in gcc-plugins-check to advise users to
      upgrade to gcc 5.2+ on powerpc to avoid issues with header files (gcc <=
      4.6) or missing copies of rs6000-cpus.def (4.8 to 5.1 on 64-bit
      Signed-off-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  19. 02 Feb, 2017 1 commit
  20. 25 Jan, 2017 3 commits
    • Christophe Leroy's avatar
      powerpc/8xx: Implement hw_breakpoint · 4ad8622d
      Christophe Leroy authored
      This patch implements HW breakpoint on the 8xx. The 8xx has
      capability to manage HW breakpoints, which is slightly different
      than BOOK3S:
      1/ The breakpoint match doesn't trigger a DSI exception but a
      dedicated data breakpoint exception.
      2/ The breakpoint happens after the instruction has completed,
      no need to single step or emulate the instruction,
      3/ Matched address is not set in DAR but in BAR,
      4/ DABR register doesn't exist, instead we have registers
      LCTRL1, LCTRL2 and CMPx registers,
      5/ The match on one comparator is not on a double word but
      on a single word.
      The patch does:
      1/ Prepare the dedicated registers in call to __set_dabr(). In order
      to emulate the double word handling of BOOK3S, comparator E is set to
      DABR address value and comparator F to address + 4. Then breakpoint 1
      is set to match comparator E or F,
      2/ Skip the singlestepping stage when compiled for CONFIG_PPC_8xx,
      3/ Implement the exception. In that exception, the matched address
      is taken from SPRN_BAR and manage as if it was from SPRN_DAR.
      4/ I/D TLB error exception routines perform a tlbie on bad TLBs. That
      tlbie triggers the breakpoint exception when performed on the
      breakpoint address. For this reason, the routine returns if the match
      is from one of those two tlbie.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarScott Wood <oss@buserror.net>
    • Christophe Leroy's avatar
      powerpc/32: Enable HW_BREAKPOINT on BOOK3S · fa769d3f
      Christophe Leroy authored
      BOOK3S also has DABR register and capability to handle data
      breakpoints, so this patch enable it on all BOOK3S, not only 64 bits.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarScott Wood <oss@buserror.net>
    • Paul Mackerras's avatar
      powerpc/64: Use optimized checksum routines on little-endian · d4fde568
      Paul Mackerras authored
      Currently we have optimized hand-coded assembly checksum routines for
      big-endian 64-bit systems, but for little-endian we use the generic C
      routines. This modifies the optimized routines to work for
      little-endian. With this, we no longer need to enable
      CONFIG_GENERIC_CSUM. This also fixes a couple of comments in
      checksum_64.S so they accurately reflect what the associated instruction
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      [mpe: Use the more common __BIG_ENDIAN__]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  21. 24 Jan, 2017 1 commit
    • Michael Ellerman's avatar
      powerpc: Revert the initial stack protector support · f2574030
      Michael Ellerman authored
      Unfortunately the stack protector support we merged recently only works
      on some toolchains. If the toolchain is built without glibc support
      everything works fine, but if glibc is built then it leads to a panic
      at boot.
      The solution is not rc5 material, so revert the support for now. This
      reverts commits:
      6533b7c1 ("powerpc: Initial stack protector (-fstack-protector) support")
      902e06eb ("powerpc/32: Change the stack protector canary value per task")
      Fixes: 6533b7c1
       ("powerpc: Initial stack protector (-fstack-protector) support")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  22. 20 Dec, 2016 1 commit
    • Thiago Jung Bauermann's avatar
      powerpc: ima: get the kexec buffer passed by the previous kernel · 467d2782
      Thiago Jung Bauermann authored
      Patch series "ima: carry the measurement list across kexec", v8.
      The TPM PCRs are only reset on a hard reboot.  In order to validate a
      TPM's quote after a soft reboot (eg.  kexec -e), the IMA measurement
      list of the running kernel must be saved and then restored on the
      subsequent boot, possibly of a different architecture.
      The existing securityfs binary_runtime_measurements file conveniently
      provides a serialized format of the IMA measurement list.  This patch
      set serializes the measurement list in this format and restores it.
      Up to now, the binary_runtime_measurements was defined as architecture
      native format.  The assumption being that userspace could and would
      handle any architecture conversions.  With the ability of carrying the
      measurement list across kexec, possibly from one architecture to a
      different one, the per boot architecture information is lost and with it
      the ability of recalculating the template digest hash.  To resolve this
      problem, without breaking the existing ABI, this patch set introduces
      the boot command line option "ima_canonical_fmt", which is arbitrarily
      defined as little endian.
      The need for this boot command line option will be limited to the
      existing version 1 format of the binary_runtime_measurements.
      Subsequent formats will be defined as canonical format (eg.  TPM 2.0
      support for larger digests).
      A simplified method of Thiago Bauermann's "kexec buffer handover" patch
      series for carrying the IMA measurement list across kexec is included in
      this patch set.  The simplified method requires all file measurements be
      taken prior to executing the kexec load, as subsequent measurements will
      not be carried across the kexec and restored.
      This patch (of 10):
      The IMA kexec buffer allows the currently running kernel to pass the
      measurement list via a kexec segment to the kernel that will be kexec'd.
      The second kernel can check whether the previous kernel sent the buffer
      and retrieve it.
      This is the architecture-specific part which enables IMA to receive the
      measurement list passed by the previous kernel.  It will be used in the
      next patch.
      The change in machine_kexec_64.c is to factor out the logic of removing
      an FDT memory reservation so that it can be used by remove_ima_buffer.
      Link: http://lkml.kernel.org/r/1480554346-29071-2-git-send-email-zohar@linux.vnet.ibm.com
      Signed-off-by: default avatarThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Andreas Steffen <andreas.steffen@strongswan.org>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      Cc: Josh Sklar <sklar@linux.vnet.ibm.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Stewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  23. 02 Dec, 2016 1 commit
    • Michael Ellerman's avatar
      powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit · f6853eb5
      Michael Ellerman authored
      This is used in poison.h to offset poison values so that they don't
      point directly into user space.
      The value we choose sits roughly between user and kernel space, which
      means on their own the poison values don't point anywhere useful. If an
      attacker can cause an access at some offset from the poison value then
      we may still be in trouble, but by putting the poison values between
      user and kernel space we maximise the required size of that offset.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  24. 30 Nov, 2016 2 commits
  25. 23 Nov, 2016 1 commit
  26. 18 Nov, 2016 1 commit
  27. 15 Nov, 2016 1 commit
  28. 14 Nov, 2016 2 commits
  29. 08 Oct, 2016 1 commit
    • Vineet Gupta's avatar
      atomic64: no need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE · 51a02124
      Vineet Gupta authored
      This came to light when implementing native 64-bit atomics for ARCv2.
      The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
      to check whether atomic64_dec_if_positive() is available.  It seems it
      was needed when not every arch defined it.  However as of current code
      the Kconfig option seems needless
       - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
         generic definition of API is present lib/atomic64.c
       - arches with native 64-bit atomics select it in arch/*/Kconfig and
         define the API in their headers
      So I see no point in keeping the Kconfig option
      Compile tested for:
       - blackfin (CONFIG_GENERIC_ATOMIC64)
       - x86 (!CONFIG_GENERIC_ATOMIC64)
       - ia64
      Link: http://lkml.kernel.org/r/1473703083-8625-3-git-send-email-vgupta@synopsys.com
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Ming Lin <ming.l@ssi.samsung.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  30. 04 Oct, 2016 1 commit
  31. 28 Sep, 2016 1 commit
  32. 20 Sep, 2016 1 commit
    • Aneesh Kumar K.V's avatar
      powerpc/mm: Update FORCE_MAX_ZONEORDER range to allow hugetlb w/4K · d5a1e42c
      Aneesh Kumar K.V authored
      For hugetlb to work with 4K page size, we need MAX_ORDER to be 13 or
      more. When switching from a 64K page size to 4K linux page size using
      make oldconfig, we end up with a CONFIG_FORCE_MAX_ZONEORDER value of 9.
      This results in a 16M hugepage beiing considered as a gigantic huge page
      which in turn results in failure to setup hugepages if gigantic hugepage
      support is not enabled.
      This also results in kernel crash with 4K radix configuration. We
      hit the below BUG_ON on radix:
        kernel BUG at mm/huge_memory.c:364!
        Oops: Exception in kernel mode, sig: 5 [#1]
        SMP NR_CPUS=2048 NUMA PowerNV
        CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1-00006-gbae9cc6 #1
        task: c0000000f1af8000 task.stack: c0000000f1aec000
        NIP: c000000000c5fa0c LR: c000000000c5f9d8 CTR: c000000000c5f9a4
        REGS: c0000000f1aef920 TRAP: 0700   Not tainted (4.8.0-rc1-00006-gbae9cc6)
        MSR: 9000000102029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE,TM[E]>  CR: 24000844  XER: 00000000
        CFAR: c000000000c5f9e0 SOFTE: 1
        NIP [c000000000c5fa0c] hugepage_init+0x68/0x238
        LR [c000000000c5f9d8] hugepage_init+0x34/0x238
      Fixes: a7ee5395
       ("powerpc/Kconfig: Update config option based on page size")
      Cc: stable@vger.kernel.org # v4.7+
      Reported-by: default avatarSanthosh <santhog4@linux.vnet.ibm.com>
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>