--- /dev/null
+From 9d75f08946e8485109458ccf16f714697c207f41 Mon Sep 17 00:00:00 2001
+From: "Hon Ching \\(Vicky\\) Lo" <honclo@linux.vnet.ibm.com>
+Date: Fri, 22 May 2015 13:23:02 -0400
+Subject: vTPM: set virtual device before passing to ibmvtpm_reset_crq
+
+From: "Hon Ching \\(Vicky\\) Lo" <honclo@linux.vnet.ibm.com>
+
+commit 9d75f08946e8485109458ccf16f714697c207f41 upstream.
+
+tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
+set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
+the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address.
+
+Signed-off-by: Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>
+Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
+Reviewed-by: Ashley Lai <ashley@ahsleylai.com>
+Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
+Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/tpm_ibmvtpm.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/char/tpm/tpm_ibmvtpm.c
++++ b/drivers/char/tpm/tpm_ibmvtpm.c
+@@ -579,6 +579,9 @@ static int tpm_ibmvtpm_probe(struct vio_
+ goto cleanup;
+ }
+
++ ibmvtpm->dev = dev;
++ ibmvtpm->vdev = vio_dev;
++
+ crq_q = &ibmvtpm->crq_queue;
+ crq_q->crq_addr = (struct ibmvtpm_crq *)get_zeroed_page(GFP_KERNEL);
+ if (!crq_q->crq_addr) {
+@@ -623,8 +626,6 @@ static int tpm_ibmvtpm_probe(struct vio_
+
+ crq_q->index = 0;
+
+- ibmvtpm->dev = dev;
+- ibmvtpm->vdev = vio_dev;
+ TPM_VPRIV(chip) = (void *)ibmvtpm;
+
+ spin_lock_init(&ibmvtpm->rtce_lock);
--- /dev/null
+From 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 Mon Sep 17 00:00:00 2001
+From: Eric Sandeen <sandeen@redhat.com>
+Date: Mon, 22 Jun 2015 09:42:48 +1000
+Subject: xfs: fix remote symlinks on V5/CRC filesystems
+
+From: Eric Sandeen <sandeen@redhat.com>
+
+commit 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 upstream.
+
+If we create a CRC filesystem, mount it, and create a symlink with
+a path long enough that it can't live in the inode, we get a very
+strange result upon remount:
+
+# ls -l mnt
+total 4
+lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM
+
+XSLM is the V5 symlink block header magic (which happens to be
+followed by a NUL, so the string looks terminated).
+
+xfs_readlink_bmap() advanced cur_chunk by the size of the header
+for CRC filesystems, but never actually used that pointer; it
+kept reading from bp->b_addr, which is the start of the block,
+rather than the start of the symlink data after the header.
+
+Looks like this problem goes back to v3.10.
+
+Fixing this gets us reading the proper link target, again.
+
+Signed-off-by: Eric Sandeen <sandeen@redhat.com>
+Reviewed-by: Dave Chinner <dchinner@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/xfs_symlink.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/xfs/xfs_symlink.c
++++ b/fs/xfs/xfs_symlink.c
+@@ -102,7 +102,7 @@ xfs_readlink_bmap(
+ cur_chunk += sizeof(struct xfs_dsymlink_hdr);
+ }
+
+- memcpy(link + offset, bp->b_addr, byte_cnt);
++ memcpy(link + offset, cur_chunk, byte_cnt);
+
+ pathlen -= byte_cnt;
+ offset += byte_cnt;