Merge branch 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

drm-intel-next-2014-01-10:
- final bits for runtime D3 on Haswell from Paul (now enabled fully)
- parse the backlight modulation freq information in the VBT from Jani
  (but not yet used)
- more watermark improvements from Ville for ilk-ivb and bdw
- bugfixes for fastboot from Jesse
- watermark fix for i830M (but not yet everything)
- vlv vga hotplug w/a (Imre)
- piles of other small improvements, cleanups and fixes all over

Note that the pull request includes a backmerge of the last drm-fixes
pulled into Linus' tree - things where getting a bit too messy. So the
shortlog also contains a bunch of patches from Linus tree. Please yell if
you want me to frob it for you a bit.

* 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel: (609 commits)
  drm/i915/bdw: make sure south port interrupts are enabled properly v2
  drm/i915: Include more information in disabled hotplug interrupt warning
  drm/i915: Only complain about a rogue hotplug IRQ after disabling
  drm/i915: Only WARN about a stuck hotplug irq ONCE
  drm/i915: s/hotplugt_status_gen4/hotplug_status_g4x/

1 files changed, 21 insertions, 0 deletions

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index ab58556d347c..377eb889f555 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3872,6 +3872,27 @@ void ata_scsi_hotplug(struct work_struct *work)
                 return;
         }
 
+        /*
+         * XXX - UGLY HACK
+         *
+         * The block layer suspend/resume path is fundamentally broken due
+         * to freezable kthreads and workqueue and may deadlock if a block
+         * device gets removed while resume is in progress.  I don't know
+         * what the solution is short of removing freezable kthreads and
+         * workqueues altogether.
+         *
+         * The following is an ugly hack to avoid kicking off device
+         * removal while freezer is active.  This is a joke but does avoid
+         * this particular deadlock scenario.
+         *
+         * https://bugzilla.kernel.org/show_bug.cgi?id=62801
+         * http://marc.info/?l=linux-kernel&m=138695698516487
+         */
+#ifdef CONFIG_FREEZER
+        while (pm_freezing)
+                msleep(10);
+#endif
+
         DPRINTK("ENTER\n");
         mutex_lock(&ap->scsi_scan_mutex);