]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.6-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 13 Nov 2012 23:22:45 +0000 (15:22 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 13 Nov 2012 23:22:45 +0000 (15:22 -0800)
added patches:
drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch
drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch
drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch
drm-vmwgfx-fix-hibernation-device-reset.patch
futex-handle-futex_pi-owner_died-take-over-correctly.patch
mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch
mmc-sh_mmcif-fix-use-after-free.patch

queue-3.6/drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch [new file with mode: 0644]
queue-3.6/drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch [new file with mode: 0644]
queue-3.6/drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch [new file with mode: 0644]
queue-3.6/drm-vmwgfx-fix-hibernation-device-reset.patch [new file with mode: 0644]
queue-3.6/futex-handle-futex_pi-owner_died-take-over-correctly.patch [new file with mode: 0644]
queue-3.6/mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch [new file with mode: 0644]
queue-3.6/mmc-sh_mmcif-fix-use-after-free.patch [new file with mode: 0644]
queue-3.6/series

diff --git a/queue-3.6/drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch b/queue-3.6/drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch
new file mode 100644 (file)
index 0000000..636afed
--- /dev/null
@@ -0,0 +1,49 @@
+From 860fe2f05fa2eacac84368e23547ec8cf3cc6652 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 8 Nov 2012 10:08:04 -0500
+Subject: drm/radeon/cayman: add some missing regs to the VM reg checker
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 860fe2f05fa2eacac84368e23547ec8cf3cc6652 upstream.
+
+These regs were being wronly rejected leading to rendering
+issues.
+
+fixes:
+https://bugs.freedesktop.org/show_bug.cgi?id=56876
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/evergreen_cs.c |    3 +++
+ drivers/gpu/drm/radeon/evergreend.h   |    4 ++++
+ 2 files changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/evergreen_cs.c
++++ b/drivers/gpu/drm/radeon/evergreen_cs.c
+@@ -2725,6 +2725,9 @@ static bool evergreen_vm_reg_valid(u32 r
+       /* check config regs */
+       switch (reg) {
+       case GRBM_GFX_INDEX:
++      case CP_STRMOUT_CNTL:
++      case CP_COHER_CNTL:
++      case CP_COHER_SIZE:
+       case VGT_VTX_VECT_EJECT_REG:
+       case VGT_CACHE_INVALIDATION:
+       case VGT_GS_VERTEX_REUSE:
+--- a/drivers/gpu/drm/radeon/evergreend.h
++++ b/drivers/gpu/drm/radeon/evergreend.h
+@@ -87,6 +87,10 @@
+ #define       CONFIG_MEMSIZE                                  0x5428
++#define       CP_STRMOUT_CNTL                                 0x84FC
++
++#define       CP_COHER_CNTL                                   0x85F0
++#define       CP_COHER_SIZE                                   0x85F4
+ #define       CP_COHER_BASE                                   0x85F8
+ #define       CP_STALLED_STAT1                        0x8674
+ #define       CP_STALLED_STAT2                        0x8678
diff --git a/queue-3.6/drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch b/queue-3.6/drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch
new file mode 100644 (file)
index 0000000..65f4520
--- /dev/null
@@ -0,0 +1,40 @@
+From f418b88aad0c42b4caf4d79a0cf8d14a5d0a2284 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 8 Nov 2012 10:13:24 -0500
+Subject: drm/radeon/si: add some missing regs to the VM reg checker
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit f418b88aad0c42b4caf4d79a0cf8d14a5d0a2284 upstream.
+
+This register is needed for streamout to work properly.
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/si.c  |    1 +
+ drivers/gpu/drm/radeon/sid.h |    1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/si.c
++++ b/drivers/gpu/drm/radeon/si.c
+@@ -2472,6 +2472,7 @@ static bool si_vm_reg_valid(u32 reg)
+       /* check config regs */
+       switch (reg) {
+       case GRBM_GFX_INDEX:
++      case CP_STRMOUT_CNTL:
+       case VGT_VTX_VECT_EJECT_REG:
+       case VGT_CACHE_INVALIDATION:
+       case VGT_ESGS_RING_SIZE:
+--- a/drivers/gpu/drm/radeon/sid.h
++++ b/drivers/gpu/drm/radeon/sid.h
+@@ -424,6 +424,7 @@
+ #       define RDERR_INT_ENABLE                         (1 << 0)
+ #       define GUI_IDLE_INT_ENABLE                      (1 << 19)
++#define       CP_STRMOUT_CNTL                                 0x84FC
+ #define       SCRATCH_REG0                                    0x8500
+ #define       SCRATCH_REG1                                    0x8504
+ #define       SCRATCH_REG2                                    0x8508
diff --git a/queue-3.6/drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch b/queue-3.6/drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch
new file mode 100644 (file)
index 0000000..79033f5
--- /dev/null
@@ -0,0 +1,31 @@
+From afcc87aa6a233e52df73552dc1dc9ae3881b7cc8 Mon Sep 17 00:00:00 2001
+From: Thomas Hellstrom <thellstrom@vmware.com>
+Date: Fri, 9 Nov 2012 10:45:14 +0100
+Subject: drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+commit afcc87aa6a233e52df73552dc1dc9ae3881b7cc8 upstream.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Reviewed-by: Brian Paul <brianp@vmware.com>
+Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
+Cc: linux-graphics-maintainer@vmware.com
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
+@@ -306,7 +306,7 @@ void vmw_bo_pin(struct ttm_buffer_object
+       BUG_ON(!atomic_read(&bo->reserved));
+       BUG_ON(old_mem_type != TTM_PL_VRAM &&
+-             old_mem_type != VMW_PL_FLAG_GMR);
++             old_mem_type != VMW_PL_GMR);
+       pl_flags = TTM_PL_FLAG_VRAM | VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED;
+       if (pin)
diff --git a/queue-3.6/drm-vmwgfx-fix-hibernation-device-reset.patch b/queue-3.6/drm-vmwgfx-fix-hibernation-device-reset.patch
new file mode 100644 (file)
index 0000000..158d9f6
--- /dev/null
@@ -0,0 +1,36 @@
+From 95e8f6a21996c4cc2c4574b231c6e858b749dce3 Mon Sep 17 00:00:00 2001
+From: Thomas Hellstrom <thellstrom@vmware.com>
+Date: Fri, 9 Nov 2012 10:05:57 +0100
+Subject: drm/vmwgfx: Fix hibernation device reset
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+commit 95e8f6a21996c4cc2c4574b231c6e858b749dce3 upstream.
+
+The device would not reset properly when resuming from hibernation.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Reviewed-by: Brian Paul <brianp@vmware.com>
+Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
+Cc: linux-graphics-maintainer@vmware.com
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |    5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+@@ -1099,6 +1099,11 @@ static void vmw_pm_complete(struct devic
+       struct drm_device *dev = pci_get_drvdata(pdev);
+       struct vmw_private *dev_priv = vmw_priv(dev);
++      mutex_lock(&dev_priv->hw_mutex);
++      vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
++      (void) vmw_read(dev_priv, SVGA_REG_ID);
++      mutex_unlock(&dev_priv->hw_mutex);
++
+       /**
+        * Reclaim 3d reference held by fbdev and potentially
+        * start fifo.
diff --git a/queue-3.6/futex-handle-futex_pi-owner_died-take-over-correctly.patch b/queue-3.6/futex-handle-futex_pi-owner_died-take-over-correctly.patch
new file mode 100644 (file)
index 0000000..ff8d502
--- /dev/null
@@ -0,0 +1,225 @@
+From 59fa6245192159ab5e1e17b8e31f15afa9cff4bf Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 23 Oct 2012 22:29:38 +0200
+Subject: futex: Handle futex_pi OWNER_DIED take over correctly
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 59fa6245192159ab5e1e17b8e31f15afa9cff4bf upstream.
+
+Siddhesh analyzed a failure in the take over of pi futexes in case the
+owner died and provided a workaround.
+See: http://sourceware.org/bugzilla/show_bug.cgi?id=14076
+
+The detailed problem analysis shows:
+
+Futex F is initialized with PTHREAD_PRIO_INHERIT and
+PTHREAD_MUTEX_ROBUST_NP attributes.
+
+T1 lock_futex_pi(F);
+
+T2 lock_futex_pi(F);
+   --> T2 blocks on the futex and creates pi_state which is associated
+       to T1.
+
+T1 exits
+   --> exit_robust_list() runs
+       --> Futex F userspace value TID field is set to 0 and
+           FUTEX_OWNER_DIED bit is set.
+
+T3 lock_futex_pi(F);
+   --> Succeeds due to the check for F's userspace TID field == 0
+   --> Claims ownership of the futex and sets its own TID into the
+       userspace TID field of futex F
+   --> returns to user space
+
+T1 --> exit_pi_state_list()
+       --> Transfers pi_state to waiter T2 and wakes T2 via
+                  rt_mutex_unlock(&pi_state->mutex)
+
+T2 --> acquires pi_state->mutex and gains real ownership of the
+       pi_state
+   --> Claims ownership of the futex and sets its own TID into the
+       userspace TID field of futex F
+   --> returns to user space
+
+T3 --> observes inconsistent state
+
+This problem is independent of UP/SMP, preemptible/non preemptible
+kernels, or process shared vs. private. The only difference is that
+certain configurations are more likely to expose it.
+
+So as Siddhesh correctly analyzed the following check in
+futex_lock_pi_atomic() is the culprit:
+
+       if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
+
+We check the userspace value for a TID value of 0 and take over the
+futex unconditionally if that's true.
+
+AFAICT this check is there as it is correct for a different corner
+case of futexes: the WAITERS bit became stale.
+
+Now the proposed change
+
+-      if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
++       if (unlikely(ownerdied ||
++                       !(curval & (FUTEX_TID_MASK | FUTEX_WAITERS)))) {
+
+solves the problem, but it's not obvious why and it wreckages the
+"stale WAITERS bit" case.
+
+What happens is, that due to the WAITERS bit being set (T2 is blocked
+on that futex) it enforces T3 to go through lookup_pi_state(), which
+in the above case returns an existing pi_state and therefor forces T3
+to legitimately fight with T2 over the ownership of the pi_state (via
+pi_state->mutex). Probelm solved!
+
+Though that does not work for the "WAITERS bit is stale" problem
+because if lookup_pi_state() does not find existing pi_state it
+returns -ERSCH (due to TID == 0) which causes futex_lock_pi() to
+return -ESRCH to user space because the OWNER_DIED bit is not set.
+
+Now there is a different solution to that problem. Do not look at the
+user space value at all and enforce a lookup of possibly available
+pi_state. If pi_state can be found, then the new incoming locker T3
+blocks on that pi_state and legitimately races with T2 to acquire the
+rt_mutex and the pi_state and therefor the proper ownership of the
+user space futex.
+
+lookup_pi_state() has the correct order of checks. It first tries to
+find a pi_state associated with the user space futex and only if that
+fails it checks for futex TID value = 0. If no pi_state is available
+nothing can create new state at that point because this happens with
+the hash bucket lock held.
+
+So the above scenario changes to:
+
+T1 lock_futex_pi(F);
+
+T2 lock_futex_pi(F);
+   --> T2 blocks on the futex and creates pi_state which is associated
+       to T1.
+
+T1 exits
+   --> exit_robust_list() runs
+       --> Futex F userspace value TID field is set to 0 and
+           FUTEX_OWNER_DIED bit is set.
+
+T3 lock_futex_pi(F);
+   --> Finds pi_state and blocks on pi_state->rt_mutex
+
+T1 --> exit_pi_state_list()
+       --> Transfers pi_state to waiter T2 and wakes it via
+                  rt_mutex_unlock(&pi_state->mutex)
+
+T2 --> acquires pi_state->mutex and gains ownership of the pi_state
+   --> Claims ownership of the futex and sets its own TID into the
+       userspace TID field of futex F
+   --> returns to user space
+
+This covers all gazillion points on which T3 might come in between
+T1's exit_robust_list() clearing the TID field and T2 fixing it up. It
+also solves the "WAITERS bit stale" problem by forcing the take over.
+
+Another benefit of changing the code this way is that it makes it less
+dependent on untrusted user space values and therefor minimizes the
+possible wreckage which might be inflicted.
+
+As usual after staring for too long at the futex code my brain hurts
+so much that I really want to ditch that whole optimization of
+avoiding the syscall for the non contended case for PI futexes and rip
+out the maze of corner case handling code. Unfortunately we can't as
+user space relies on that existing behaviour, but at least thinking
+about it helps me to preserve my mental sanity. Maybe we should
+nevertheless :)
+
+Reported-and-tested-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
+Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1210232138540.2756@ionos
+Acked-by: Darren Hart <dvhart@linux.intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/futex.c |   41 ++++++++++++++++++++++-------------------
+ 1 file changed, 22 insertions(+), 19 deletions(-)
+
+--- a/kernel/futex.c
++++ b/kernel/futex.c
+@@ -716,7 +716,7 @@ static int futex_lock_pi_atomic(u32 __us
+                               struct futex_pi_state **ps,
+                               struct task_struct *task, int set_waiters)
+ {
+-      int lock_taken, ret, ownerdied = 0;
++      int lock_taken, ret, force_take = 0;
+       u32 uval, newval, curval, vpid = task_pid_vnr(task);
+ retry:
+@@ -755,17 +755,15 @@ retry:
+       newval = curval | FUTEX_WAITERS;
+       /*
+-       * There are two cases, where a futex might have no owner (the
+-       * owner TID is 0): OWNER_DIED. We take over the futex in this
+-       * case. We also do an unconditional take over, when the owner
+-       * of the futex died.
+-       *
+-       * This is safe as we are protected by the hash bucket lock !
++       * Should we force take the futex? See below.
+        */
+-      if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
+-              /* Keep the OWNER_DIED bit */
++      if (unlikely(force_take)) {
++              /*
++               * Keep the OWNER_DIED and the WAITERS bit and set the
++               * new TID value.
++               */
+               newval = (curval & ~FUTEX_TID_MASK) | vpid;
+-              ownerdied = 0;
++              force_take = 0;
+               lock_taken = 1;
+       }
+@@ -775,7 +773,7 @@ retry:
+               goto retry;
+       /*
+-       * We took the lock due to owner died take over.
++       * We took the lock due to forced take over.
+        */
+       if (unlikely(lock_taken))
+               return 1;
+@@ -790,20 +788,25 @@ retry:
+               switch (ret) {
+               case -ESRCH:
+                       /*
+-                       * No owner found for this futex. Check if the
+-                       * OWNER_DIED bit is set to figure out whether
+-                       * this is a robust futex or not.
++                       * We failed to find an owner for this
++                       * futex. So we have no pi_state to block
++                       * on. This can happen in two cases:
++                       *
++                       * 1) The owner died
++                       * 2) A stale FUTEX_WAITERS bit
++                       *
++                       * Re-read the futex value.
+                        */
+                       if (get_futex_value_locked(&curval, uaddr))
+                               return -EFAULT;
+                       /*
+-                       * We simply start over in case of a robust
+-                       * futex. The code above will take the futex
+-                       * and return happy.
++                       * If the owner died or we have a stale
++                       * WAITERS bit the owner TID in the user space
++                       * futex is 0.
+                        */
+-                      if (curval & FUTEX_OWNER_DIED) {
+-                              ownerdied = 1;
++                      if (!(curval & FUTEX_TID_MASK)) {
++                              force_take = 1;
+                               goto retry;
+                       }
+               default:
diff --git a/queue-3.6/mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch b/queue-3.6/mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch
new file mode 100644 (file)
index 0000000..5bd3809
--- /dev/null
@@ -0,0 +1,52 @@
+From 14efd957209461bbdf285bf0d67e931955d04a4c Mon Sep 17 00:00:00 2001
+From: Chris Ball <cjb@laptop.org>
+Date: Mon, 5 Nov 2012 14:29:49 -0500
+Subject: mmc: sdhci: fix NULL dereference in sdhci_request() tuning
+
+From: Chris Ball <cjb@laptop.org>
+
+commit 14efd957209461bbdf285bf0d67e931955d04a4c upstream.
+
+Commit 473b095a72a9 ("mmc: sdhci: fix incorrect command used in tuning")
+introduced a NULL dereference at resume-time if an SD 3.0 host controller
+raises the SDHCI_NEEDS_TUNING flag while no card is inserted.  Seen on an
+OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too.
+
+Signed-off-by: Chris Ball <cjb@laptop.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci.c |   21 ++++++++++++---------
+ 1 file changed, 12 insertions(+), 9 deletions(-)
+
+--- a/drivers/mmc/host/sdhci.c
++++ b/drivers/mmc/host/sdhci.c
+@@ -1307,16 +1307,19 @@ static void sdhci_request(struct mmc_hos
+                */
+               if ((host->flags & SDHCI_NEEDS_RETUNING) &&
+                   !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
+-                      /* eMMC uses cmd21 while sd and sdio use cmd19 */
+-                      tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
+-                              MMC_SEND_TUNING_BLOCK_HS200 :
+-                              MMC_SEND_TUNING_BLOCK;
+-                      spin_unlock_irqrestore(&host->lock, flags);
+-                      sdhci_execute_tuning(mmc, tuning_opcode);
+-                      spin_lock_irqsave(&host->lock, flags);
++                      if (mmc->card) {
++                              /* eMMC uses cmd21 but sd and sdio use cmd19 */
++                              tuning_opcode =
++                                      mmc->card->type == MMC_TYPE_MMC ?
++                                      MMC_SEND_TUNING_BLOCK_HS200 :
++                                      MMC_SEND_TUNING_BLOCK;
++                              spin_unlock_irqrestore(&host->lock, flags);
++                              sdhci_execute_tuning(mmc, tuning_opcode);
++                              spin_lock_irqsave(&host->lock, flags);
+-                      /* Restore original mmc_request structure */
+-                      host->mrq = mrq;
++                              /* Restore original mmc_request structure */
++                              host->mrq = mrq;
++                      }
+               }
+               if (mrq->sbc && !(host->flags & SDHCI_AUTO_CMD23))
diff --git a/queue-3.6/mmc-sh_mmcif-fix-use-after-free.patch b/queue-3.6/mmc-sh_mmcif-fix-use-after-free.patch
new file mode 100644 (file)
index 0000000..91c58e0
--- /dev/null
@@ -0,0 +1,35 @@
+From a0d28ba01ebd048b4ba418142b37f5cf80e6d156 Mon Sep 17 00:00:00 2001
+From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+Date: Tue, 23 Oct 2012 14:08:52 +0200
+Subject: mmc: sh_mmcif: fix use after free
+
+From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+
+commit a0d28ba01ebd048b4ba418142b37f5cf80e6d156 upstream.
+
+A recent commit "mmc: sh_mmcif: fix clock management" has introduced a
+use after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to
+mmc_free_host() frees private driver data, therefore using it afterwards
+is a bug. Revert that hunk.
+
+Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+Signed-off-by: Chris Ball <cjb@laptop.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sh_mmcif.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sh_mmcif.c
++++ b/drivers/mmc/host/sh_mmcif.c
+@@ -1464,9 +1464,9 @@ static int __devexit sh_mmcif_remove(str
+       platform_set_drvdata(pdev, NULL);
++      clk_disable(host->hclk);
+       mmc_free_host(host->mmc);
+       pm_runtime_put_sync(&pdev->dev);
+-      clk_disable(host->hclk);
+       pm_runtime_disable(&pdev->dev);
+       return 0;
index ffab1f80c4582295764190f1851f05d51b8314b1..d9d1fc5ea9feecc5c171bd5c68d304db9f5048e9 100644 (file)
@@ -55,3 +55,10 @@ tcp-repair-handle-zero-length-data-put-in-rcv-queue.patch
 net-inet_diag-return-error-code-if-protocol-handler-is-missed.patch
 af-packet-fix-oops-when-socket-is-not-present.patch
 ipv6-send-unsolicited-neighbour-advertisements-to-all-nodes.patch
+futex-handle-futex_pi-owner_died-take-over-correctly.patch
+mmc-sh_mmcif-fix-use-after-free.patch
+mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch
+drm-vmwgfx-fix-hibernation-device-reset.patch
+drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch
+drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch
+drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch