--- /dev/null
+From 09bfda10e6efd7b65bcc29237bee1765ed779657 Mon Sep 17 00:00:00 2001
+From: Jeffery Miller <jmiller@neverware.com>
+Date: Tue, 1 Sep 2015 11:23:02 -0400
+Subject: Add radeon suspend/resume quirk for HP Compaq dc5750.
+
+From: Jeffery Miller <jmiller@neverware.com>
+
+commit 09bfda10e6efd7b65bcc29237bee1765ed779657 upstream.
+
+With the radeon driver loaded the HP Compaq dc5750
+Small Form Factor machine fails to resume from suspend.
+Adding a quirk similar to other devices avoids
+the problem and the system resumes properly.
+
+Signed-off-by: Jeffery Miller <jmiller@neverware.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_combios.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_combios.c
++++ b/drivers/gpu/drm/radeon/radeon_combios.c
+@@ -3387,6 +3387,14 @@ void radeon_combios_asic_init(struct drm
+ rdev->pdev->subsystem_device == 0x30ae)
+ return;
+
++ /* quirk for rs4xx HP Compaq dc5750 Small Form Factor to make it resume
++ * - it hangs on resume inside the dynclk 1 table.
++ */
++ if (rdev->family == CHIP_RS480 &&
++ rdev->pdev->subsystem_vendor == 0x103c &&
++ rdev->pdev->subsystem_device == 0x280a)
++ return;
++
+ /* DYN CLK 1 */
+ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE);
+ if (table)
--- /dev/null
+From 4c17a6d56bb0cad3066a714e94f7185a24b40f49 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jann@thejh.net>
+Date: Fri, 11 Sep 2015 16:27:27 +0200
+Subject: CIFS: fix type confusion in copy offload ioctl
+
+From: Jann Horn <jann@thejh.net>
+
+commit 4c17a6d56bb0cad3066a714e94f7185a24b40f49 upstream.
+
+This might lead to local privilege escalation (code execution as
+kernel) for systems where the following conditions are met:
+
+ - CONFIG_CIFS_SMB2 and CONFIG_CIFS_POSIX are enabled
+ - a cifs filesystem is mounted where:
+ - the mount option "vers" was used and set to a value >=2.0
+ - the attacker has write access to at least one file on the filesystem
+
+To attack this, an attacker would have to guess the target_tcon
+pointer (but guessing wrong doesn't cause a crash, it just returns an
+error code) and win a narrow race.
+
+Signed-off-by: Jann Horn <jann@thejh.net>
+Signed-off-by: Steve French <smfrench@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/ioctl.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/fs/cifs/ioctl.c
++++ b/fs/cifs/ioctl.c
+@@ -70,6 +70,12 @@ static long cifs_ioctl_clone(unsigned in
+ goto out_drop_write;
+ }
+
++ if (src_file.file->f_op->unlocked_ioctl != cifs_ioctl) {
++ rc = -EBADF;
++ cifs_dbg(VFS, "src file seems to be from a different filesystem type\n");
++ goto out_fput;
++ }
++
+ if ((!src_file.file->private_data) || (!dst_file->private_data)) {
+ rc = -EBADF;
+ cifs_dbg(VFS, "missing cifsFileInfo on copy range src file\n");
--- /dev/null
+From 2d6f0600b2cd755959527230ef5a6fba97bb762a Mon Sep 17 00:00:00 2001
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+Date: Mon, 13 Jul 2015 13:51:39 -0300
+Subject: crypto: vmx - Adding enable_kernel_vsx() to access VSX instructions
+
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+
+commit 2d6f0600b2cd755959527230ef5a6fba97bb762a upstream.
+
+vmx-crypto driver make use of some VSX instructions which are
+only available if VSX is enabled. Running in cases where VSX
+are not enabled vmx-crypto fails in a VSX exception.
+
+In order to fix this enable_kernel_vsx() was added to turn on
+VSX instructions for vmx-crypto.
+
+Signed-off-by: Leonidas S. Barbosa <leosilva@linux.vnet.ibm.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/vmx/aes.c | 3 +++
+ drivers/crypto/vmx/aes_cbc.c | 3 +++
+ drivers/crypto/vmx/aes_ctr.c | 3 +++
+ drivers/crypto/vmx/ghash.c | 4 ++++
+ 4 files changed, 13 insertions(+)
+
+--- a/drivers/crypto/vmx/aes.c
++++ b/drivers/crypto/vmx/aes.c
+@@ -84,6 +84,7 @@ static int p8_aes_setkey(struct crypto_t
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ ret = aes_p8_set_encrypt_key(key, keylen * 8, &ctx->enc_key);
+ ret += aes_p8_set_decrypt_key(key, keylen * 8, &ctx->dec_key);
+ pagefault_enable();
+@@ -103,6 +104,7 @@ static void p8_aes_encrypt(struct crypto
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ aes_p8_encrypt(src, dst, &ctx->enc_key);
+ pagefault_enable();
+ preempt_enable();
+@@ -119,6 +121,7 @@ static void p8_aes_decrypt(struct crypto
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ aes_p8_decrypt(src, dst, &ctx->dec_key);
+ pagefault_enable();
+ preempt_enable();
+--- a/drivers/crypto/vmx/aes_cbc.c
++++ b/drivers/crypto/vmx/aes_cbc.c
+@@ -85,6 +85,7 @@ static int p8_aes_cbc_setkey(struct cryp
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ ret = aes_p8_set_encrypt_key(key, keylen * 8, &ctx->enc_key);
+ ret += aes_p8_set_decrypt_key(key, keylen * 8, &ctx->dec_key);
+ pagefault_enable();
+@@ -115,6 +116,7 @@ static int p8_aes_cbc_encrypt(struct blk
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+
+ blkcipher_walk_init(&walk, dst, src, nbytes);
+ ret = blkcipher_walk_virt(desc, &walk);
+@@ -155,6 +157,7 @@ static int p8_aes_cbc_decrypt(struct blk
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+
+ blkcipher_walk_init(&walk, dst, src, nbytes);
+ ret = blkcipher_walk_virt(desc, &walk);
+--- a/drivers/crypto/vmx/aes_ctr.c
++++ b/drivers/crypto/vmx/aes_ctr.c
+@@ -82,6 +82,7 @@ static int p8_aes_ctr_setkey(struct cryp
+
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ ret = aes_p8_set_encrypt_key(key, keylen * 8, &ctx->enc_key);
+ pagefault_enable();
+
+@@ -100,6 +101,7 @@ static void p8_aes_ctr_final(struct p8_a
+
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ aes_p8_encrypt(ctrblk, keystream, &ctx->enc_key);
+ pagefault_enable();
+
+@@ -132,6 +134,7 @@ static int p8_aes_ctr_crypt(struct blkci
+ while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ aes_p8_ctr32_encrypt_blocks(walk.src.virt.addr,
+ walk.dst.virt.addr,
+ (nbytes &
+--- a/drivers/crypto/vmx/ghash.c
++++ b/drivers/crypto/vmx/ghash.c
+@@ -119,6 +119,7 @@ static int p8_ghash_setkey(struct crypto
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ enable_kernel_fp();
+ gcm_init_p8(ctx->htable, (const u64 *) key);
+ pagefault_enable();
+@@ -149,6 +150,7 @@ static int p8_ghash_update(struct shash_
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ enable_kernel_fp();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ dctx->buffer, GHASH_DIGEST_SIZE);
+@@ -163,6 +165,7 @@ static int p8_ghash_update(struct shash_
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ enable_kernel_fp();
+ gcm_ghash_p8(dctx->shash, ctx->htable, src, len);
+ pagefault_enable();
+@@ -193,6 +196,7 @@ static int p8_ghash_final(struct shash_d
+ preempt_disable();
+ pagefault_disable();
+ enable_kernel_altivec();
++ enable_kernel_vsx();
+ enable_kernel_fp();
+ gcm_ghash_p8(dctx->shash, ctx->htable,
+ dctx->buffer, GHASH_DIGEST_SIZE);
--- /dev/null
+From 1ab36387ea4face01aac3560b396b1e2ce07c4ff Mon Sep 17 00:00:00 2001
+From: David Dueck <davidcdueck@googlemail.com>
+Date: Tue, 28 Jul 2015 09:48:16 +0200
+Subject: pinctrl: at91: fix null pointer dereference
+
+From: David Dueck <davidcdueck@googlemail.com>
+
+commit 1ab36387ea4face01aac3560b396b1e2ce07c4ff upstream.
+
+Not all gpio banks are necessarily enabled, in the current code this can
+lead to null pointer dereferences.
+
+[ 51.130000] Unable to handle kernel NULL pointer dereference at virtual address 00000058
+[ 51.130000] pgd = dee04000
+[ 51.130000] [00000058] *pgd=3f66d831, *pte=00000000, *ppte=00000000
+[ 51.140000] Internal error: Oops: 17 [#1] ARM
+[ 51.140000] Modules linked in:
+[ 51.140000] CPU: 0 PID: 1664 Comm: cat Not tainted 4.1.1+ #6
+[ 51.140000] Hardware name: Atmel SAMA5
+[ 51.140000] task: df6dd880 ti: dec60000 task.ti: dec60000
+[ 51.140000] PC is at at91_pinconf_get+0xb4/0x200
+[ 51.140000] LR is at at91_pinconf_get+0xb4/0x200
+[ 51.140000] pc : [<c01e71a0>] lr : [<c01e71a0>] psr: 600f0013
+sp : dec61e48 ip : 600f0013 fp : df522538
+[ 51.140000] r10: df52250c r9 : 00000058 r8 : 00000068
+[ 51.140000] r7 : 00000000 r6 : df53c910 r5 : 00000000 r4 : dec61e7c
+[ 51.140000] r3 : 00000000 r2 : c06746d4 r1 : 00000000 r0 : 00000003
+[ 51.140000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
+[ 51.140000] Control: 10c53c7d Table: 3ee04059 DAC: 00000015
+[ 51.140000] Process cat (pid: 1664, stack limit = 0xdec60208)
+[ 51.140000] Stack: (0xdec61e48 to 0xdec62000)
+[ 51.140000] 1e40: 00000358 00000000 df522500 ded15f80 c05a9d08 ded15f80
+[ 51.140000] 1e60: 0000048c 00000061 df522500 ded15f80 c05a9d08 c01e7304 ded15f80 00000000
+[ 51.140000] 1e80: c01e6008 00000060 0000048c c01e6034 c01e5f6c ded15f80 dec61ec0 00000000
+[ 51.140000] 1ea0: 00020000 ded6f280 dec61f80 00000001 00000001 c00ae0b8 b6e80000 ded15fb0
+[ 51.140000] 1ec0: 00000000 00000000 df4bc974 00000055 00000800 ded6f280 b6e80000 ded6f280
+[ 51.140000] 1ee0: ded6f280 00020000 b6e80000 00000000 00020000 c0090dec c0671e1c dec61fb0
+[ 51.140000] 1f00: b6f8b510 00000001 00004201 c000924c 00000000 00000003 00000003 00000000
+[ 51.140000] 1f20: df4bc940 00022000 00000022 c066e188 b6e7f000 c00836f4 000b6e7f ded6f280
+[ 51.140000] 1f40: ded6f280 b6e80000 dec61f80 ded6f280 00020000 c0091508 00000000 00000003
+[ 51.140000] 1f60: 00022000 00000000 00000000 ded6f280 ded6f280 00020000 b6e80000 c0091d9c
+[ 51.140000] 1f80: 00000000 00000000 ffffffff 00020000 00020000 b6e80000 00000003 c000f124
+[ 51.140000] 1fa0: dec60000 c000efa0 00020000 00020000 00000003 b6e80000 00020000 000271c4
+[ 51.140000] 1fc0: 00020000 00020000 b6e80000 00000003 7fffe000 00000000 00000000 00020000
+[ 51.140000] 1fe0: 00000000 bef50b64 00013835 b6f29c76 400f0030 00000003 00000000 00000000
+[ 51.140000] [<c01e71a0>] (at91_pinconf_get) from [<c01e7304>] (at91_pinconf_dbg_show+0x18/0x2c0)
+[ 51.140000] [<c01e7304>] (at91_pinconf_dbg_show) from [<c01e6034>] (pinconf_pins_show+0xc8/0xf8)
+[ 51.140000] [<c01e6034>] (pinconf_pins_show) from [<c00ae0b8>] (seq_read+0x1a0/0x464)
+[ 51.140000] [<c00ae0b8>] (seq_read) from [<c0090dec>] (__vfs_read+0x20/0xd0)
+[ 51.140000] [<c0090dec>] (__vfs_read) from [<c0091508>] (vfs_read+0x7c/0x108)
+[ 51.140000] [<c0091508>] (vfs_read) from [<c0091d9c>] (SyS_read+0x40/0x94)
+[ 51.140000] [<c0091d9c>] (SyS_read) from [<c000efa0>] (ret_fast_syscall+0x0/0x3c)
+[ 51.140000] Code: eb010ec2 e30a0d08 e34c005a eb0ae5a7 (e5993000)
+[ 51.150000] ---[ end trace fb3c370da3ea4794 ]---
+
+Fixes: a0b957f306fa ("pinctrl: at91: allow to have disabled gpio bank")
+Signed-off-by: David Dueck <davidcdueck@googlemail.com>
+Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
+Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
+Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
+Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
+Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-at91.c | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+--- a/drivers/pinctrl/pinctrl-at91.c
++++ b/drivers/pinctrl/pinctrl-at91.c
+@@ -320,6 +320,9 @@ static const struct pinctrl_ops at91_pct
+ static void __iomem *pin_to_controller(struct at91_pinctrl *info,
+ unsigned int bank)
+ {
++ if (!gpio_chips[bank])
++ return NULL;
++
+ return gpio_chips[bank]->regbase;
+ }
+
+@@ -729,6 +732,10 @@ static int at91_pmx_set(struct pinctrl_d
+ pin = &pins_conf[i];
+ at91_pin_dbg(info->dev, pin);
+ pio = pin_to_controller(info, pin->bank);
++
++ if (!pio)
++ continue;
++
+ mask = pin_to_mask(pin->pin);
+ at91_mux_disable_interrupt(pio, mask);
+ switch (pin->mux) {
+@@ -848,6 +855,10 @@ static int at91_pinconf_get(struct pinct
+ *config = 0;
+ dev_dbg(info->dev, "%s:%d, pin_id=%d", __func__, __LINE__, pin_id);
+ pio = pin_to_controller(info, pin_to_bank(pin_id));
++
++ if (!pio)
++ return -EINVAL;
++
+ pin = pin_id % MAX_NB_GPIO_PER_BANK;
+
+ if (at91_mux_get_multidrive(pio, pin))
+@@ -889,6 +900,10 @@ static int at91_pinconf_set(struct pinct
+ "%s:%d, pin_id=%d, config=0x%lx",
+ __func__, __LINE__, pin_id, config);
+ pio = pin_to_controller(info, pin_to_bank(pin_id));
++
++ if (!pio)
++ return -EINVAL;
++
+ pin = pin_id % MAX_NB_GPIO_PER_BANK;
+ mask = pin_to_mask(pin);
+
--- /dev/null
+From 655471f54c2e395ba29ae4156ba0f49928177cc1 Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Tue, 15 Sep 2015 11:24:17 +1000
+Subject: powerpc/boot: Specify ABI v2 when building an LE boot wrapper
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+commit 655471f54c2e395ba29ae4156ba0f49928177cc1 upstream.
+
+The kernel does it, not the boot wrapper, which breaks with some
+cross compilers that still default to ABI v1.
+
+Fixes: 147c05168fc8 ("powerpc/boot: Add support for 64bit little endian wrapper")
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/boot/Makefile | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/powerpc/boot/Makefile
++++ b/arch/powerpc/boot/Makefile
+@@ -28,6 +28,9 @@ BOOTCFLAGS += -m64
+ endif
+ ifdef CONFIG_CPU_BIG_ENDIAN
+ BOOTCFLAGS += -mbig-endian
++else
++BOOTCFLAGS += -mlittle-endian
++BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
+ endif
+
+ BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
--- /dev/null
+From 259800135c654a098d9f0adfdd3d1f20eef1f231 Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Date: Fri, 28 Aug 2015 11:57:00 +1000
+Subject: powerpc/eeh: Fix fenced PHB caused by eeh_slot_error_detail()
+
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+
+commit 259800135c654a098d9f0adfdd3d1f20eef1f231 upstream.
+
+The config space of some PCI devices can't be accessed when their
+PEs are in frozen state. Otherwise, fenced PHB might be seen.
+Those PEs are identified with flag EEH_PE_CFG_RESTRICTED, meaing
+EEH_PE_CFG_BLOCKED is set automatically when the PE is put to
+frozen state (EEH_PE_ISOLATED). eeh_slot_error_detail() restores
+PCI device BARs with eeh_pe_restore_bars(), which then calls
+eeh_ops->restore_config() to reinitialize the PCI device in
+(OPAL) firmware. eeh_ops->restore_config() produces PCI config
+access that causes fenced PHB. The problem was reported on below
+adapter:
+
+ 0001:01:00.0 0200: 14e4:168e (rev 10)
+ 0001:01:00.0 Ethernet controller: Broadcom Corporation \
+ NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)
+
+This fixes the issue by skipping eeh_pe_restore_bars() in
+eeh_slot_error_detail() when EEH_PE_CFG_BLOCKED is set for the PE.
+
+Fixes: b6541db1 ("powerpc/eeh: Block PCI config access upon frozen PE")
+Reported-by: Manvanthara B. Puttashankar <mputtash@in.ibm.com>
+Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/eeh.c | 21 ++++++++++++++++++---
+ 1 file changed, 18 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/kernel/eeh.c
++++ b/arch/powerpc/kernel/eeh.c
+@@ -308,11 +308,26 @@ void eeh_slot_error_detail(struct eeh_pe
+ if (!(pe->type & EEH_PE_PHB)) {
+ if (eeh_has_flag(EEH_ENABLE_IO_FOR_LOG))
+ eeh_pci_enable(pe, EEH_OPT_THAW_MMIO);
++
++ /*
++ * The config space of some PCI devices can't be accessed
++ * when their PEs are in frozen state. Otherwise, fenced
++ * PHB might be seen. Those PEs are identified with flag
++ * EEH_PE_CFG_RESTRICTED, indicating EEH_PE_CFG_BLOCKED
++ * is set automatically when the PE is put to EEH_PE_ISOLATED.
++ *
++ * Restoring BARs possibly triggers PCI config access in
++ * (OPAL) firmware and then causes fenced PHB. If the
++ * PCI config is blocked with flag EEH_PE_CFG_BLOCKED, it's
++ * pointless to restore BARs and dump config space.
++ */
+ eeh_ops->configure_bridge(pe);
+- eeh_pe_restore_bars(pe);
++ if (!(pe->state & EEH_PE_CFG_BLOCKED)) {
++ eeh_pe_restore_bars(pe);
+
+- pci_regs_buf[0] = 0;
+- eeh_pe_traverse(pe, eeh_dump_pe_log, &loglen);
++ pci_regs_buf[0] = 0;
++ eeh_pe_traverse(pe, eeh_dump_pe_log, &loglen);
++ }
+ }
+
+ eeh_ops->get_log(pe, severity, pci_regs_buf, loglen);
--- /dev/null
+From e642d11bdbfe8eb10116ab3959a2b5d75efda832 Mon Sep 17 00:00:00 2001
+From: Daniel Axtens <dja@axtens.net>
+Date: Fri, 14 Aug 2015 16:03:19 +1000
+Subject: powerpc/eeh: Probe after unbalanced kref check
+
+From: Daniel Axtens <dja@axtens.net>
+
+commit e642d11bdbfe8eb10116ab3959a2b5d75efda832 upstream.
+
+In the complete hotplug case, EEH PEs are supposed to be released
+and set to NULL. Normally, this is done by eeh_remove_device(),
+which is called from pcibios_release_device().
+
+However, if something is holding a kref to the device, it will not
+be released, and the PE will remain. eeh_add_device_late() has
+a check for this which will explictly destroy the PE in this case.
+
+This check in eeh_add_device_late() occurs after a call to
+eeh_ops->probe(). On PowerNV, probe is a pointer to pnv_eeh_probe(),
+which will exit without probing if there is an existing PE.
+
+This means that on PowerNV, devices with outstanding krefs will not
+be rediscovered by EEH correctly after a complete hotplug. This is
+affecting CXL (CAPI) devices in the field.
+
+Put the probe after the kref check so that the PE is destroyed
+and affected devices are correctly rediscovered by EEH.
+
+Fixes: d91dafc02f42 ("powerpc/eeh: Delay probing EEH device during hotplug")
+Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Daniel Axtens <dja@axtens.net>
+Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/eeh.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/kernel/eeh.c
++++ b/arch/powerpc/kernel/eeh.c
+@@ -1116,9 +1116,6 @@ void eeh_add_device_late(struct pci_dev
+ return;
+ }
+
+- if (eeh_has_flag(EEH_PROBE_MODE_DEV))
+- eeh_ops->probe(pdn, NULL);
+-
+ /*
+ * The EEH cache might not be removed correctly because of
+ * unbalanced kref to the device during unplug time, which
+@@ -1142,6 +1139,9 @@ void eeh_add_device_late(struct pci_dev
+ dev->dev.archdata.edev = NULL;
+ }
+
++ if (eeh_has_flag(EEH_PROBE_MODE_DEV))
++ eeh_ops->probe(pdn, NULL);
++
+ edev->pdev = dev;
+ dev->dev.archdata.edev = edev;
+
--- /dev/null
+From 74b5037baa2011a2799e2c43adde7d171b072f9e Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Fri, 7 Aug 2015 16:19:43 +1000
+Subject: powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+commit 74b5037baa2011a2799e2c43adde7d171b072f9e upstream.
+
+The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
+PAGE_SIZE.
+
+However when built with a 4K PAGE_SIZE there is an additional config
+option which can be enabled, PPC_HAS_HASH_64K, which means the kernel
+also knows how to hash a 64K page even though the base PAGE_SIZE is 4K.
+
+This is used in one obscure configuration, to support 64K pages for SPU
+local store on the Cell processor when the rest of the kernel is using
+4K pages.
+
+In this configuration, pte_pagesize_index() is defined to just pass
+through its arguments to get_slice_psize(). However pte_pagesize_index()
+is called for both user and kernel addresses, whereas get_slice_psize()
+only knows how to handle user addresses.
+
+This has been broken forever, however until recently it happened to
+work. That was because in get_slice_psize() the large kernel address
+would cause the right shift of the slice mask to return zero.
+
+However in commit 7aa0727f3302 ("powerpc/mm: Increase the slice range to
+64TB"), the get_slice_psize() code was changed so that instead of a
+right shift we do an array lookup based on the address. When passed a
+kernel address this means we index way off the end of the slice array
+and return random junk.
+
+That is only fatal if we happen to hit something non-zero, but when we
+do return a non-zero value we confuse the MMU code and eventually cause
+a check stop.
+
+This fix is ugly, but simple. When we're called for a kernel address we
+return 4K, which is always correct in this configuration, otherwise we
+use the slice mask.
+
+Fixes: 7aa0727f3302 ("powerpc/mm: Increase the slice range to 64TB")
+Reported-by: Cyril Bur <cyrilbur@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/pgtable-ppc64.h | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/include/asm/pgtable-ppc64.h
++++ b/arch/powerpc/include/asm/pgtable-ppc64.h
+@@ -135,7 +135,19 @@
+ #define pte_iterate_hashed_end() } while(0)
+
+ #ifdef CONFIG_PPC_HAS_HASH_64K
+-#define pte_pagesize_index(mm, addr, pte) get_slice_psize(mm, addr)
++/*
++ * We expect this to be called only for user addresses or kernel virtual
++ * addresses other than the linear mapping.
++ */
++#define pte_pagesize_index(mm, addr, pte) \
++ ({ \
++ unsigned int psize; \
++ if (is_kernel_addr(addr)) \
++ psize = MMU_PAGE_4K; \
++ else \
++ psize = get_slice_psize(mm, addr); \
++ psize; \
++ })
+ #else
+ #define pte_pagesize_index(mm, addr, pte) MMU_PAGE_4K
+ #endif
--- /dev/null
+From 36b35d5d807b7e57aff7d08e63de8b17731ee211 Mon Sep 17 00:00:00 2001
+From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
+Date: Tue, 15 Sep 2015 12:30:08 +0530
+Subject: powerpc/mm: Recompute hash value after a failed update
+
+From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
+
+commit 36b35d5d807b7e57aff7d08e63de8b17731ee211 upstream.
+
+If we had secondary hash flag set, we ended up modifying hash value in
+the updatepp code path. Hence with a failed updatepp we will be using
+a wrong hash value for the following hash insert. Fix this by
+recomputing hash before insert.
+
+Without this patch we can end up with using wrong slot number in linux
+pte. That can result in us missing an hash pte update or invalidate
+which can cause memory corruption or even machine check.
+
+Fixes: 6d492ecc6489 ("powerpc/THP: Add code to handle HPTE faults for hugepages")
+Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
+Reviewed-by: Paul Mackerras <paulus@samba.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/mm/hugepage-hash64.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/mm/hugepage-hash64.c
++++ b/arch/powerpc/mm/hugepage-hash64.c
+@@ -85,7 +85,6 @@ int __hash_page_thp(unsigned long ea, un
+ BUG_ON(index >= 4096);
+
+ vpn = hpt_vpn(ea, vsid, ssize);
+- hash = hpt_hash(vpn, shift, ssize);
+ hpte_slot_array = get_hpte_slot_array(pmdp);
+ if (psize == MMU_PAGE_4K) {
+ /*
+@@ -101,6 +100,7 @@ int __hash_page_thp(unsigned long ea, un
+ valid = hpte_valid(hpte_slot_array, index);
+ if (valid) {
+ /* update the hpte bits */
++ hash = hpt_hash(vpn, shift, ssize);
+ hidx = hpte_hash_index(hpte_slot_array, index);
+ if (hidx & _PTEIDX_SECONDARY)
+ hash = ~hash;
+@@ -126,6 +126,7 @@ int __hash_page_thp(unsigned long ea, un
+ if (!valid) {
+ unsigned long hpte_group;
+
++ hash = hpt_hash(vpn, shift, ssize);
+ /* insert new entry */
+ pa = pmd_pfn(__pmd(old_pmd)) << PAGE_SHIFT;
+ new_pmd |= _PAGE_HASHPTE;
--- /dev/null
+From bb0054552d080dd929907c5925d4bedc8bf6def7 Mon Sep 17 00:00:00 2001
+From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
+Date: Wed, 2 Sep 2015 08:39:28 -0700
+Subject: powerpc/powernv/pci-ioda: fix 32-bit TCE table init in kdump kernel
+
+From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
+
+commit bb0054552d080dd929907c5925d4bedc8bf6def7 upstream.
+
+When attempting to kdump with the 4.2 kernel, we see for each PCI
+device:
+
+ pci 0003:01 : [PE# 000] Assign DMA32 space
+ pci 0003:01 : [PE# 000] Setting up 32-bit TCE table at 0..80000000
+ pci 0003:01 : [PE# 000] Failed to create 32-bit TCE table, err -22
+ PCI: Domain 0004 has 8 available 32-bit DMA segments
+ PCI: 4 PE# for a total weight of 70
+ pci 0004:01 : [PE# 002] Assign DMA32 space
+ pci 0004:01 : [PE# 002] Setting up 32-bit TCE table at 0..80000000
+ pci 0004:01 : [PE# 002] Failed to create 32-bit TCE table, err -22
+ pci 0004:0d : [PE# 005] Assign DMA32 space
+ pci 0004:0d : [PE# 005] Setting up 32-bit TCE table at 0..80000000
+ pci 0004:0d : [PE# 005] Failed to create 32-bit TCE table, err -22
+ pci 0004:0e : [PE# 006] Assign DMA32 space
+ pci 0004:0e : [PE# 006] Setting up 32-bit TCE table at 0..80000000
+ pci 0004:0e : [PE# 006] Failed to create 32-bit TCE table, err -22
+ pci 0004:10 : [PE# 008] Assign DMA32 space
+ pci 0004:10 : [PE# 008] Setting up 32-bit TCE table at 0..80000000
+ pci 0004:10 : [PE# 008] Failed to create 32-bit TCE table, err -22
+
+and eventually the kdump kernel fails to boot as none of the PCI devices
+(including the disk controller) are successfully initialized.
+
+The EINVAL response is because the DMA window (the 2GB base window) is
+larger than the kdump kernel's reserved memory (crashkernel=, in this
+case specified to be 1024M). The check in question,
+
+ if ((window_size > memory_hotplug_max()) || !is_power_of_2(window_size))
+
+is a valid sanity check for pnv_pci_ioda2_table_alloc_pages(), so adjust
+the caller to pass in a smaller window size if our maximum memory value
+is smaller than the DMA window.
+
+After this change, the PCI devices successfully set up the 32-bit TCE
+table and kdump succeeds.
+
+The problem was seen on a Firestone machine originally.
+
+Fixes: aca6913f5551 ("powerpc/powernv/ioda2: Introduce helpers to allocate TCE pages")
+Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
+Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
+[mpe: Coding style pedantry, use u64, change the indentation]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/powernv/pci-ioda.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/platforms/powernv/pci-ioda.c
++++ b/arch/powerpc/platforms/powernv/pci-ioda.c
+@@ -2078,9 +2078,17 @@ static long pnv_pci_ioda2_setup_default_
+ struct iommu_table *tbl = NULL;
+ long rc;
+
++ /*
++ * In memory constrained environments, e.g. kdump kernel, the
++ * DMA window can be larger than available memory, which will
++ * cause errors later.
++ */
++ const u64 window_size = min((u64)pe->table_group.tce32_size,
++ memory_hotplug_max());
++
+ rc = pnv_pci_ioda2_create_table(&pe->table_group, 0,
+ IOMMU_PAGE_SHIFT_4K,
+- pe->table_group.tce32_size,
++ window_size,
+ POWERNV_IOMMU_DEFAULT_LEVELS, &tbl);
+ if (rc) {
+ pe_err(pe, "Failed to create 32-bit TCE table, err %ld",
--- /dev/null
+From fa14486979b3a47307bcdb10f8b5baa875a5cf68 Mon Sep 17 00:00:00 2001
+From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
+Date: Fri, 4 Sep 2015 11:22:52 -0700
+Subject: powerpc/powernv/pci-ioda: fix kdump with non-power-of-2 crashkernel=
+
+From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
+
+commit fa14486979b3a47307bcdb10f8b5baa875a5cf68 upstream.
+
+The 32-bit TCE table initialization relies on the DMA window having a
+size equal to a power of 2 (and checks for it explicitly). But
+crashkernel= has no constraint that requires a power-of-2 be specified.
+This causes the kdump kernel to fail to boot as none of the PCI devices
+(including the disk controller) are successfully initialized.
+
+After this change, the PCI devices successfully set up the 32-bit TCE
+table and kdump succeeds.
+
+Fixes: aca6913f5551 ("powerpc/powernv/ioda2: Introduce helpers to allocate TCE pages")
+Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
+Tested-by: Jan Stancek <jstancek@redhat.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/powernv/pci-ioda.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/powernv/pci-ioda.c
++++ b/arch/powerpc/platforms/powernv/pci-ioda.c
+@@ -2079,12 +2079,18 @@ static long pnv_pci_ioda2_setup_default_
+ long rc;
+
+ /*
++ * crashkernel= specifies the kdump kernel's maximum memory at
++ * some offset and there is no guaranteed the result is a power
++ * of 2, which will cause errors later.
++ */
++ const u64 max_memory = __rounddown_pow_of_two(memory_hotplug_max());
++
++ /*
+ * In memory constrained environments, e.g. kdump kernel, the
+ * DMA window can be larger than available memory, which will
+ * cause errors later.
+ */
+- const u64 window_size = min((u64)pe->table_group.tce32_size,
+- memory_hotplug_max());
++ const u64 window_size = min((u64)pe->table_group.tce32_size, max_memory);
+
+ rc = pnv_pci_ioda2_create_table(&pe->table_group, 0,
+ IOMMU_PAGE_SHIFT_4K,
--- /dev/null
+From 590c7567a2895f939525ead57b0334c6d47986f0 Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Date: Thu, 27 Aug 2015 14:12:36 +1000
+Subject: powerpc/pseries: Fix corrupted pdn list
+
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+
+commit 590c7567a2895f939525ead57b0334c6d47986f0 upstream.
+
+Commit cca87d30 ("powerpc/pci: Refactor pci_dn") introduced pdn
+list for SRIOV VFs. It means the pdn is be put into the child list
+of its parent pdn when the pdn is created. When doing PCI hot
+unplugging on pSeries, the PCI device node as well as its pdn are
+released through procfs entry "powerpc/ofdt". Some one else grabs
+the memory chunk of the pdn and update it accordingly. At the same
+time, the pdn is still tracked in the child list of parent pdn. It
+leads to corrupted child list in the parent pdn.
+
+This fixes above issue by removing the pdn from the child list of
+its parent pdn when the device node is detached from the system.
+Note the pdn is free'd when the device node is released if the
+device node is dynamic one. Otherwise, the device node as well
+as the pdn won't be released.
+
+Fixes: cca87d30 ("powerpc/pci: Refactor pci_dn")
+Reported-by: Santwana Samantray <santwana.samantray@in.ibm.com>
+Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/pseries/setup.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/powerpc/platforms/pseries/setup.c
++++ b/arch/powerpc/platforms/pseries/setup.c
+@@ -268,6 +268,11 @@ static int pci_dn_reconfig_notifier(stru
+ eeh_dev_init(PCI_DN(np), pci->phb);
+ }
+ break;
++ case OF_RECONFIG_DETACH_NODE:
++ pci = PCI_DN(np);
++ if (pci)
++ list_del(&pci->list);
++ break;
+ default:
+ err = NOTIFY_DONE;
+ break;
--- /dev/null
+From daebaabb5cfbe4a6f09ca0e0f8b7673efc704960 Mon Sep 17 00:00:00 2001
+From: Bharata B Rao <bharata@linux.vnet.ibm.com>
+Date: Mon, 7 Sep 2015 15:52:40 +0530
+Subject: powerpc/pseries: Release DRC when configure_connector fails
+
+From: Bharata B Rao <bharata@linux.vnet.ibm.com>
+
+commit daebaabb5cfbe4a6f09ca0e0f8b7673efc704960 upstream.
+
+Commit f32393c943e2 ("powerpc/pseries: Correct cpu affinity for
+dlpar added cpus") moved dlpar_acquire_drc() call to before
+dlpar_configure_connector() call in dlpar_cpu_probe(), but missed
+to release the DRC if dlpar_configure_connector() failed.
+During CPU hotplug, if configure-connector fails for any reason,
+then this will result in subsequent CPU hotplug attempts to fail.
+
+Release the acquired DRC if dlpar_configure_connector() call fails
+so that the DRC is left in right isolation and allocation state
+for the subsequent hotplug operation to succeed.
+
+Fixes: f32393c943e2 ("powerpc/pseries: Correct cpu affinity for dlpar added cpus")
+Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
+Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/pseries/dlpar.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/platforms/pseries/dlpar.c
++++ b/arch/powerpc/platforms/pseries/dlpar.c
+@@ -422,8 +422,10 @@ static ssize_t dlpar_cpu_probe(const cha
+
+ dn = dlpar_configure_connector(cpu_to_be32(drc_index), parent);
+ of_node_put(parent);
+- if (!dn)
++ if (!dn) {
++ dlpar_release_drc(drc_index);
+ return -EINVAL;
++ }
+
+ rc = dlpar_attach_node(dn);
+ if (rc) {
--- /dev/null
+From 1c2cb594441d02815d304cccec9742ff5c707495 Mon Sep 17 00:00:00 2001
+From: Thomas Huth <thuth@redhat.com>
+Date: Fri, 17 Jul 2015 12:46:58 +0200
+Subject: powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers
+
+From: Thomas Huth <thuth@redhat.com>
+
+commit 1c2cb594441d02815d304cccec9742ff5c707495 upstream.
+
+The EPOW interrupt handler uses rtas_get_sensor(), which in turn
+uses rtas_busy_delay() to wait for RTAS becoming ready in case it
+is necessary. But rtas_busy_delay() is annotated with might_sleep()
+and thus may not be used by interrupts handlers like the EPOW handler!
+This leads to the following BUG when CONFIG_DEBUG_ATOMIC_SLEEP is
+enabled:
+
+ BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:496
+ in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
+ CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #6
+ Call Trace:
+ [c00000007ffe7b90] [c000000000807670] dump_stack+0xa0/0xdc (unreliable)
+ [c00000007ffe7bc0] [c0000000000e1f14] ___might_sleep+0x134/0x180
+ [c00000007ffe7c20] [c00000000002aec0] rtas_busy_delay+0x30/0xd0
+ [c00000007ffe7c50] [c00000000002bde4] rtas_get_sensor+0x74/0xe0
+ [c00000007ffe7ce0] [c000000000083264] ras_epow_interrupt+0x44/0x450
+ [c00000007ffe7d90] [c000000000120260] handle_irq_event_percpu+0xa0/0x300
+ [c00000007ffe7e70] [c000000000120524] handle_irq_event+0x64/0xc0
+ [c00000007ffe7eb0] [c000000000124dbc] handle_fasteoi_irq+0xec/0x260
+ [c00000007ffe7ef0] [c00000000011f4f0] generic_handle_irq+0x50/0x80
+ [c00000007ffe7f20] [c000000000010f3c] __do_irq+0x8c/0x200
+ [c00000007ffe7f90] [c0000000000236cc] call_do_irq+0x14/0x24
+ [c00000007e6f39e0] [c000000000011144] do_IRQ+0x94/0x110
+ [c00000007e6f3a30] [c000000000002594] hardware_interrupt_common+0x114/0x180
+
+Fix this issue by introducing a new rtas_get_sensor_fast() function
+that does not use rtas_busy_delay() - and thus can only be used for
+sensors that do not cause a BUSY condition - known as "fast" sensors.
+
+The EPOW sensor is defined to be "fast" in sPAPR - mpe.
+
+Fixes: 587f83e8dd50 ("powerpc/pseries: Use rtas_get_sensor in RAS code")
+Signed-off-by: Thomas Huth <thuth@redhat.com>
+Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/rtas.h | 1 +
+ arch/powerpc/kernel/rtas.c | 17 +++++++++++++++++
+ arch/powerpc/platforms/pseries/ras.c | 3 ++-
+ 3 files changed, 20 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/include/asm/rtas.h
++++ b/arch/powerpc/include/asm/rtas.h
+@@ -343,6 +343,7 @@ extern void rtas_power_off(void);
+ extern void rtas_halt(void);
+ extern void rtas_os_term(char *str);
+ extern int rtas_get_sensor(int sensor, int index, int *state);
++extern int rtas_get_sensor_fast(int sensor, int index, int *state);
+ extern int rtas_get_power_level(int powerdomain, int *level);
+ extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
+ extern bool rtas_indicator_present(int token, int *maxindex);
+--- a/arch/powerpc/kernel/rtas.c
++++ b/arch/powerpc/kernel/rtas.c
+@@ -584,6 +584,23 @@ int rtas_get_sensor(int sensor, int inde
+ }
+ EXPORT_SYMBOL(rtas_get_sensor);
+
++int rtas_get_sensor_fast(int sensor, int index, int *state)
++{
++ int token = rtas_token("get-sensor-state");
++ int rc;
++
++ if (token == RTAS_UNKNOWN_SERVICE)
++ return -ENOENT;
++
++ rc = rtas_call(token, 2, 2, state, sensor, index);
++ WARN_ON(rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
++ rc <= RTAS_EXTENDED_DELAY_MAX));
++
++ if (rc < 0)
++ return rtas_error_rc(rc);
++ return rc;
++}
++
+ bool rtas_indicator_present(int token, int *maxindex)
+ {
+ int proplen, count, i;
+--- a/arch/powerpc/platforms/pseries/ras.c
++++ b/arch/powerpc/platforms/pseries/ras.c
+@@ -189,7 +189,8 @@ static irqreturn_t ras_epow_interrupt(in
+ int state;
+ int critical;
+
+- status = rtas_get_sensor(EPOW_SENSOR_TOKEN, EPOW_SENSOR_INDEX, &state);
++ status = rtas_get_sensor_fast(EPOW_SENSOR_TOKEN, EPOW_SENSOR_INDEX,
++ &state);
+
+ if (state > 3)
+ critical = 1; /* Time Critical */
--- /dev/null
+From 72cd7b44bc99376b3f3c93cedcd052663fcdf705 Mon Sep 17 00:00:00 2001
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+Date: Mon, 13 Jul 2015 13:51:01 -0300
+Subject: powerpc: Uncomment and make enable_kernel_vsx() routine available
+
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+
+commit 72cd7b44bc99376b3f3c93cedcd052663fcdf705 upstream.
+
+enable_kernel_vsx() function was commented since anything was using
+it. However, vmx-crypto driver uses VSX instructions which are
+only available if VSX is enable. Otherwise it rises an exception oops.
+
+This patch uncomment enable_kernel_vsx() routine and makes it available.
+
+Signed-off-by: Leonidas S. Barbosa <leosilva@linux.vnet.ibm.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/switch_to.h | 1 +
+ arch/powerpc/kernel/process.c | 3 ---
+ 2 files changed, 1 insertion(+), 3 deletions(-)
+
+--- a/arch/powerpc/include/asm/switch_to.h
++++ b/arch/powerpc/include/asm/switch_to.h
+@@ -29,6 +29,7 @@ static inline void save_early_sprs(struc
+
+ extern void enable_kernel_fp(void);
+ extern void enable_kernel_altivec(void);
++extern void enable_kernel_vsx(void);
+ extern int emulate_altivec(struct pt_regs *);
+ extern void __giveup_vsx(struct task_struct *);
+ extern void giveup_vsx(struct task_struct *);
+--- a/arch/powerpc/kernel/process.c
++++ b/arch/powerpc/kernel/process.c
+@@ -204,8 +204,6 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_threa
+ #endif /* CONFIG_ALTIVEC */
+
+ #ifdef CONFIG_VSX
+-#if 0
+-/* not currently used, but some crazy RAID module might want to later */
+ void enable_kernel_vsx(void)
+ {
+ WARN_ON(preemptible());
+@@ -220,7 +218,6 @@ void enable_kernel_vsx(void)
+ #endif /* CONFIG_SMP */
+ }
+ EXPORT_SYMBOL(enable_kernel_vsx);
+-#endif
+
+ void giveup_vsx(struct task_struct *tsk)
+ {
alsa-hda-add-some-fixup-quirks-for-white-noise-on-dell-laptop.patch
alsa-hda-fix-white-noise-on-dell-m3800.patch
pinctrl-mediatek-fix-multiple-registration-issue.patch
+pinctrl-at91-fix-null-pointer-dereference.patch
+powerpc-pseries-fix-corrupted-pdn-list.patch
+powerpc-eeh-probe-after-unbalanced-kref-check.patch
+powerpc-eeh-fix-fenced-phb-caused-by-eeh_slot_error_detail.patch
+powerpc-mm-fix-pte_pagesize_index-crash-on-4k-w-64k-hash.patch
+powerpc-rtas-introduce-rtas_get_sensor_fast-for-irq-handlers.patch
+powerpc-uncomment-and-make-enable_kernel_vsx-routine-available.patch
+crypto-vmx-adding-enable_kernel_vsx-to-access-vsx-instructions.patch
+powerpc-powernv-pci-ioda-fix-32-bit-tce-table-init-in-kdump-kernel.patch
+powerpc-powernv-pci-ioda-fix-kdump-with-non-power-of-2-crashkernel.patch
+powerpc-pseries-release-drc-when-configure_connector-fails.patch
+powerpc-boot-specify-abi-v2-when-building-an-le-boot-wrapper.patch
+powerpc-mm-recompute-hash-value-after-a-failed-update.patch
+cifs-fix-type-confusion-in-copy-offload-ioctl.patch
+add-radeon-suspend-resume-quirk-for-hp-compaq-dc5750.patch