--- /dev/null
+From 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Wed, 17 Jul 2013 14:51:28 +0200
+Subject: drm/i915: correctly restore fences with objects attached
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 upstream.
+
+To avoid stalls we delay tiling changes and especially hold of
+committing the new fence state for as long as possible.
+Synchronization points are in the execbuf code and in our gtt fault
+handler.
+
+Unfortunately we've missed that tricky detail when adding proper fence
+restore code in
+
+commit 19b2dbde5732170a03bd82cc8bd442cf88d856f7
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Wed Jun 12 10:15:12 2013 +0100
+
+ drm/i915: Restore fences after resume and GPU resets
+
+The result was that we've restored fences for objects with no tiling,
+since the object<->fence link still existed after resume. Now that
+wouldn't have been too bad since any subsequent access would have
+fixed things up, but if we've changed from tiled to untiled real havoc
+happened:
+
+The tiling stride is stored -1 in the fence register, so a stride of 0
+resulted in all 1s in the top 32bits, and so a completely bogus fence
+spanning everything from the start of the object to the top of the
+GTT. The tell-tale in the register dumps looks like:
+
+ FENCE START 2: 0x0214d001
+ FENCE END 2: 0xfffff3ff
+
+Bit 11 isn't set since the hw doesn't store it, even when writing all
+1s (at least on my snb here).
+
+To prevent such a gaffle in the future add a sanity check for fences
+with an untiled object attached in i915_gem_write_fence.
+
+v2: Fix the WARN, spotted by Chris.
+
+v3: Trying to reuse get_fences looked ugly and obfuscated the code.
+Instead reuse update_fence and to make it really dtrt also move the
+fence dirty state clearing into update_fence.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Stéphane Marchesin <marcheu@chromium.org>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Tested-by: Matthew Garrett <matthew.garrett@nebula.com>
+Tested-by: Björn Bidar <theodorstormgrade@gmail.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 18 ++++++++++++++++--
+ 1 file changed, 16 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -2138,7 +2138,17 @@ void i915_gem_restore_fences(struct drm_
+
+ for (i = 0; i < dev_priv->num_fence_regs; i++) {
+ struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i];
+- i915_gem_write_fence(dev, i, reg->obj);
++
++ /*
++ * Commit delayed tiling changes if we have an object still
++ * attached to the fence, otherwise just clear the fence.
++ */
++ if (reg->obj) {
++ i915_gem_object_update_fence(reg->obj, reg,
++ reg->obj->tiling_mode);
++ } else {
++ i915_gem_write_fence(dev, i, NULL);
++ }
+ }
+ }
+
+@@ -2676,6 +2686,10 @@ static void i915_gem_write_fence(struct
+ if (i915_gem_object_needs_mb(dev_priv->fence_regs[reg].obj))
+ mb();
+
++ WARN(obj && (!obj->stride || !obj->tiling_mode),
++ "bogus fence setup with stride: 0x%x, tiling mode: %i\n",
++ obj->stride, obj->tiling_mode);
++
+ switch (INTEL_INFO(dev)->gen) {
+ case 7:
+ case 6:
+@@ -2735,6 +2749,7 @@ static void i915_gem_object_update_fence
+ fence->obj = NULL;
+ list_del_init(&fence->lru_list);
+ }
++ obj->fence_dirty = false;
+ }
+
+ static int
+@@ -2864,7 +2879,6 @@ i915_gem_object_get_fence(struct drm_i91
+ return 0;
+
+ i915_gem_object_update_fence(obj, reg, enable);
+- obj->fence_dirty = false;
+
+ return 0;
+ }
--- /dev/null
+From 2e57f47d317dd035b18634b0c602272529368fcc Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Wed, 17 Jul 2013 12:14:40 +0100
+Subject: drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off()
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 2e57f47d317dd035b18634b0c602272529368fcc upstream.
+
+In commit e3de42b68478a8c95dd27520e9adead2af9477a5
+Author: Imre Deak <imre.deak@intel.com>
+Date: Fri May 3 19:44:07 2013 +0200
+
+ drm/i915: force full modeset if the connector is in DPMS OFF mode
+
+a new function was added that walked over the set of connectors to see
+if any of the currently associated CRTC was switched off. This function
+walked an array of connectors, rather than the array of pointers to
+connectors contained in the drm_mode_set - i.e. it was dereferencing far
+past the end of the first connector. This only becomes an issue if we
+attempt to use a clone mode (i.e. more than one connector per CRTC) such
+that set->num_connectors > 1.
+
+Reported-by: Timo Aaltonen <tjaalton@ubuntu.com>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Imre Deak <imre.deak@intel.com>
+Cc: Egbert Eich <eich@suse.de>
+Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 23 +++++++++++++----------
+ 1 file changed, 13 insertions(+), 10 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -8146,15 +8146,20 @@ static void intel_set_config_restore_sta
+ }
+
+ static bool
+-is_crtc_connector_off(struct drm_crtc *crtc, struct drm_connector *connectors,
+- int num_connectors)
++is_crtc_connector_off(struct drm_mode_set *set)
+ {
+ int i;
+
+- for (i = 0; i < num_connectors; i++)
+- if (connectors[i].encoder &&
+- connectors[i].encoder->crtc == crtc &&
+- connectors[i].dpms != DRM_MODE_DPMS_ON)
++ if (set->num_connectors == 0)
++ return false;
++
++ if (WARN_ON(set->connectors == NULL))
++ return false;
++
++ for (i = 0; i < set->num_connectors; i++)
++ if (set->connectors[i]->encoder &&
++ set->connectors[i]->encoder->crtc == set->crtc &&
++ set->connectors[i]->dpms != DRM_MODE_DPMS_ON)
+ return true;
+
+ return false;
+@@ -8167,10 +8172,8 @@ intel_set_config_compute_mode_changes(st
+
+ /* We should be able to check here if the fb has the same properties
+ * and then just flip_or_move it */
+- if (set->connectors != NULL &&
+- is_crtc_connector_off(set->crtc, *set->connectors,
+- set->num_connectors)) {
+- config->mode_changed = true;
++ if (is_crtc_connector_off(set)) {
++ config->mode_changed = true;
+ } else if (set->crtc->fb != set->fb) {
+ /* If we have no fb then treat it as a full mode set */
+ if (set->crtc->fb == NULL) {
--- /dev/null
+From d18b9619034230b6f945e215276425636ca401fe Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Wed, 10 Jul 2013 13:36:23 +0100
+Subject: drm/i915: Fix incoherence with fence updates on Sandybridge+
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit d18b9619034230b6f945e215276425636ca401fe upstream.
+
+This hopefully fixes the root cause behind the workaround added in
+
+commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu Apr 4 21:31:03 2013 +0100
+
+ drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
+
+Thanks to further investigation by Jon Bloomfield, he realised that
+the 64-bit register might be broken up by the hardware into two 32-bit
+writes (a problem we have encountered elsewhere). This non-atomicity
+would then cause an issue where a second thread would see an
+intermediate register state (new high dword, old low dword), and this
+register would randomly be used in preference to its own thread register.
+This would cause the second thread to read from and write into a fairly
+random tiled location. Breaking the operation into 3 explicit 32-bit
+updates (first disable the fence, poke the upper bits, then poke the lower
+bits and enable) ensures that, given proper serialisation between the
+32-bit register write and the memory transfer, that the fence value is
+always consistent.
+
+Armed with this knowledge, we can explain how the previous workaround
+work. The key to the corruption is that a second thread sees an
+erroneous fence register that conflicts and overrides its own. By
+serialising the fence update across all CPUs, we have a small window
+where no GTT access is occurring and so hide the potential corruption.
+This also leads to the conclusion that the earlier workaround was
+incomplete.
+
+v2: Be overly paranoid about the order in which fence updates become
+visible to the GPU to make really sure that we turn the fence off before
+doing the update, and then only switch the fence on afterwards.
+
+Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Carsten Emde <C.Emde@osadl.org>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 30 ++++++++++++++++++++++++------
+ 1 file changed, 24 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -2538,7 +2538,6 @@ static void i965_write_fence_reg(struct
+ drm_i915_private_t *dev_priv = dev->dev_private;
+ int fence_reg;
+ int fence_pitch_shift;
+- uint64_t val;
+
+ if (INTEL_INFO(dev)->gen >= 6) {
+ fence_reg = FENCE_REG_SANDYBRIDGE_0;
+@@ -2548,8 +2547,23 @@ static void i965_write_fence_reg(struct
+ fence_pitch_shift = I965_FENCE_PITCH_SHIFT;
+ }
+
++ fence_reg += reg * 8;
++
++ /* To w/a incoherency with non-atomic 64-bit register updates,
++ * we split the 64-bit update into two 32-bit writes. In order
++ * for a partial fence not to be evaluated between writes, we
++ * precede the update with write to turn off the fence register,
++ * and only enable the fence as the last step.
++ *
++ * For extra levels of paranoia, we make sure each step lands
++ * before applying the next step.
++ */
++ I915_WRITE(fence_reg, 0);
++ POSTING_READ(fence_reg);
++
+ if (obj) {
+ u32 size = obj->gtt_space->size;
++ uint64_t val;
+
+ val = (uint64_t)((obj->gtt_offset + size - 4096) &
+ 0xfffff000) << 32;
+@@ -2558,12 +2572,16 @@ static void i965_write_fence_reg(struct
+ if (obj->tiling_mode == I915_TILING_Y)
+ val |= 1 << I965_FENCE_TILING_Y_SHIFT;
+ val |= I965_FENCE_REG_VALID;
+- } else
+- val = 0;
+
+- fence_reg += reg * 8;
+- I915_WRITE64(fence_reg, val);
+- POSTING_READ(fence_reg);
++ I915_WRITE(fence_reg + 4, val >> 32);
++ POSTING_READ(fence_reg + 4);
++
++ I915_WRITE(fence_reg + 0, val);
++ POSTING_READ(fence_reg);
++ } else {
++ I915_WRITE(fence_reg + 4, 0);
++ POSTING_READ(fence_reg + 4);
++ }
+ }
+
+ static void i915_write_fence_reg(struct drm_device *dev, int reg,
--- /dev/null
+From 7dcd2677ea912573d9ed4bcd629b0023b2d11505 Mon Sep 17 00:00:00 2001
+From: Konstantin Khlebnikov <khlebnikov@openvz.org>
+Date: Wed, 17 Jul 2013 10:22:58 +0400
+Subject: drm/i915: fix long-standing SNB regression in power consumption after resume v2
+
+From: Konstantin Khlebnikov <khlebnikov@openvz.org>
+
+commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 upstream.
+
+This patch fixes regression in power consumtion of sandy bridge gpu, which
+exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
+it's extremely busy. After that it never reaches rc6 state.
+
+Bug exists since kernel v3.6:
+
+commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
+Author: Jesse Barnes <jbarnes@virtuousgeek.org>
+Date: Thu Jun 14 11:04:48 2012 -0700
+
+ drm/i915: load boot context at driver init time
+
+For some reason RC6 is already enabled at the beginning of resuming process.
+Following initliaztion breaks some internal state and confuses RPS engine.
+This patch disables RC6 at the beginnig of resume and initialization.
+
+I've rearranged initialization sequence, because intel_disable_gt_powersave()
+needs initialized force_wake_get/put and some locks from the dev_priv.
+
+Note: The culprit in the initialization sequence seems to be the write
+to MBCTL added in the above mentioned commit. The first version of
+this patch just held a forcewake reference across the clock gating
+init functions, which seems to have been enought to gather quite a few
+positive test reports. But since that smelled a bit like ad-hoc
+duct-tape v2 now just disables rps/rc6 across the entire hw setup.
+
+References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
+References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
+References: https://patchwork.kernel.org/patch/2827634/ (patch v1)
+Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
+[danvet: Add note about v1 vs. v2 of this patch and use standard
+layout for the commit citation. Also add the tested-bys from v1 and a
+cc: stable.]
+Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1)
+Tested-by: rocko <rockorequin@hotmail.com> (v1)
+Tested-by: JohnMB <johnmbryant@sky.com> (v1)
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_dma.c | 16 ++++++++--------
+ drivers/gpu/drm/i915/intel_pm.c | 5 +++--
+ 2 files changed, 11 insertions(+), 10 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_dma.c
++++ b/drivers/gpu/drm/i915/i915_dma.c
+@@ -1511,6 +1511,13 @@ int i915_driver_load(struct drm_device *
+ dev_priv->dev = dev;
+ dev_priv->info = info;
+
++ spin_lock_init(&dev_priv->irq_lock);
++ spin_lock_init(&dev_priv->gpu_error.lock);
++ spin_lock_init(&dev_priv->rps.lock);
++ mutex_init(&dev_priv->dpio_lock);
++ mutex_init(&dev_priv->rps.hw_lock);
++ mutex_init(&dev_priv->modeset_restore_lock);
++
+ i915_dump_device_info(dev_priv);
+
+ if (i915_get_bridge_dev(dev)) {
+@@ -1602,6 +1609,7 @@ int i915_driver_load(struct drm_device *
+
+ intel_irq_init(dev);
+ intel_gt_init(dev);
++ intel_gt_reset(dev);
+
+ /* Try to make sure MCHBAR is enabled before poking at it */
+ intel_setup_mchbar(dev);
+@@ -1626,14 +1634,6 @@ int i915_driver_load(struct drm_device *
+ if (!IS_I945G(dev) && !IS_I945GM(dev))
+ pci_enable_msi(dev->pdev);
+
+- spin_lock_init(&dev_priv->irq_lock);
+- spin_lock_init(&dev_priv->gpu_error.lock);
+- spin_lock_init(&dev_priv->rps.lock);
+- mutex_init(&dev_priv->dpio_lock);
+-
+- mutex_init(&dev_priv->rps.hw_lock);
+- mutex_init(&dev_priv->modeset_restore_lock);
+-
+ dev_priv->num_plane = 1;
+ if (IS_VALLEYVIEW(dev))
+ dev_priv->num_plane = 2;
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -4497,6 +4497,9 @@ void intel_gt_reset(struct drm_device *d
+ if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
+ __gen6_gt_force_wake_mt_reset(dev_priv);
+ }
++
++ /* BIOS often leaves RC6 enabled, but disable it for hw init */
++ intel_disable_gt_powersave(dev);
+ }
+
+ void intel_gt_init(struct drm_device *dev)
+@@ -4505,8 +4508,6 @@ void intel_gt_init(struct drm_device *de
+
+ spin_lock_init(&dev_priv->gt_lock);
+
+- intel_gt_reset(dev);
+-
+ if (IS_VALLEYVIEW(dev)) {
+ dev_priv->gt.force_wake_get = vlv_force_wake_get;
+ dev_priv->gt.force_wake_put = vlv_force_wake_put;
--- /dev/null
+From e1b4d3036c07ff137955fb1c0197ab62534f46ec Mon Sep 17 00:00:00 2001
+From: Ben Widawsky <ben@bwidawsk.net>
+Date: Tue, 30 Jul 2013 16:27:57 -0700
+Subject: drm/i915: fix missed hunk after GT access breakage
+
+From: Ben Widawsky <ben@bwidawsk.net>
+
+commit e1b4d3036c07ff137955fb1c0197ab62534f46ec upstream.
+
+Upon some code refactoring, a hunk was missed. This was fixed for
+next, but missed the current trees, and hasn't yet been merged by Dave
+Airlie. It is fixed in:
+commit 907b28c56ea40629aa6595ddfa414ec2fc7da41c
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Fri Jul 19 20:36:52 2013 +0100
+
+ drm/i915: Colocate all GT access routines in the same file
+
+It is introduced by:
+commit 181d1b9e31c668259d3798c521672afb8edd355c
+Author: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Sun Jul 21 13:16:24 2013 +0200
+
+ drm/i915: fix up gt init sequence fallout
+
+Reported-by: Dave Jones <davej@redhat.com>
+Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_dma.c | 1 +
+ drivers/gpu/drm/i915/i915_drv.h | 1 +
+ drivers/gpu/drm/i915/intel_pm.c | 6 ++++++
+ 3 files changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_dma.c
++++ b/drivers/gpu/drm/i915/i915_dma.c
+@@ -1608,6 +1608,7 @@ int i915_driver_load(struct drm_device *
+ intel_detect_pch(dev);
+
+ intel_irq_init(dev);
++ intel_pm_init(dev);
+ intel_gt_sanitize(dev);
+ intel_gt_init(dev);
+
+--- a/drivers/gpu/drm/i915/i915_drv.h
++++ b/drivers/gpu/drm/i915/i915_drv.h
+@@ -1475,6 +1475,7 @@ void i915_hangcheck_elapsed(unsigned lon
+ void i915_handle_error(struct drm_device *dev, bool wedged);
+
+ extern void intel_irq_init(struct drm_device *dev);
++extern void intel_pm_init(struct drm_device *dev);
+ extern void intel_hpd_init(struct drm_device *dev);
+ extern void intel_gt_init(struct drm_device *dev);
+ extern void intel_gt_sanitize(struct drm_device *dev);
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -4548,6 +4548,12 @@ void intel_gt_init(struct drm_device *de
+ dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get;
+ dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put;
+ }
++}
++
++void intel_pm_init(struct drm_device *dev)
++{
++ struct drm_i915_private *dev_priv = dev->dev_private;
++
+ INIT_DELAYED_WORK(&dev_priv->rps.delayed_resume_work,
+ intel_gen6_powersave_work);
+ }
--- /dev/null
+From 181d1b9e31c668259d3798c521672afb8edd355c Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Sun, 21 Jul 2013 13:16:24 +0200
+Subject: drm/i915: fix up gt init sequence fallout
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 181d1b9e31c668259d3798c521672afb8edd355c upstream.
+
+The regression fix for gen6+ rps fallout
+
+commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505
+Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
+Date: Wed Jul 17 10:22:58 2013 +0400
+
+ drm/i915: fix long-standing SNB regression in power consumption after resume
+
+unintentionally also changed the init sequence ordering between
+gt_init and gt_reset - we need to reset BIOS damage like leftover
+forcewake references before we run our own code. Otherwise we can get
+nasty dmesg noise like
+
+[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
+
+again. Since _reset suggests that we first need to have stuff
+initialized (which isn't the case here) call it sanitze instead.
+
+While at it also block out the rps disable introduced by the above
+commit on ilk: We don't have any knowledge of ilk rps being broken in
+similar ways. And the disable functions uses the default hw state
+which is only read out when we're enabling rps. So essentially we've
+been writing random grabage into that register.
+
+Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
+Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
+Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_dma.c | 2 +-
+ drivers/gpu/drm/i915/i915_drv.c | 4 ++--
+ drivers/gpu/drm/i915/i915_drv.h | 2 +-
+ drivers/gpu/drm/i915/intel_pm.c | 5 +++--
+ 4 files changed, 7 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_dma.c
++++ b/drivers/gpu/drm/i915/i915_dma.c
+@@ -1608,8 +1608,8 @@ int i915_driver_load(struct drm_device *
+ intel_detect_pch(dev);
+
+ intel_irq_init(dev);
++ intel_gt_sanitize(dev);
+ intel_gt_init(dev);
+- intel_gt_reset(dev);
+
+ /* Try to make sure MCHBAR is enabled before poking at it */
+ intel_setup_mchbar(dev);
+--- a/drivers/gpu/drm/i915/i915_drv.c
++++ b/drivers/gpu/drm/i915/i915_drv.c
+@@ -685,7 +685,7 @@ static int i915_drm_thaw(struct drm_devi
+ {
+ int error = 0;
+
+- intel_gt_reset(dev);
++ intel_gt_sanitize(dev);
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ mutex_lock(&dev->struct_mutex);
+@@ -711,7 +711,7 @@ int i915_resume(struct drm_device *dev)
+
+ pci_set_master(dev->pdev);
+
+- intel_gt_reset(dev);
++ intel_gt_sanitize(dev);
+
+ /*
+ * Platforms with opregion should have sane BIOS, older ones (gen3 and
+--- a/drivers/gpu/drm/i915/i915_drv.h
++++ b/drivers/gpu/drm/i915/i915_drv.h
+@@ -1477,7 +1477,7 @@ void i915_handle_error(struct drm_device
+ extern void intel_irq_init(struct drm_device *dev);
+ extern void intel_hpd_init(struct drm_device *dev);
+ extern void intel_gt_init(struct drm_device *dev);
+-extern void intel_gt_reset(struct drm_device *dev);
++extern void intel_gt_sanitize(struct drm_device *dev);
+
+ void i915_error_state_free(struct kref *error_ref);
+
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -4486,7 +4486,7 @@ static void vlv_force_wake_put(struct dr
+ gen6_gt_check_fifodbg(dev_priv);
+ }
+
+-void intel_gt_reset(struct drm_device *dev)
++void intel_gt_sanitize(struct drm_device *dev)
+ {
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+@@ -4499,7 +4499,8 @@ void intel_gt_reset(struct drm_device *d
+ }
+
+ /* BIOS often leaves RC6 enabled, but disable it for hw init */
+- intel_disable_gt_powersave(dev);
++ if (INTEL_INFO(dev)->gen >= 6)
++ intel_disable_gt_powersave(dev);
+ }
+
+ void intel_gt_init(struct drm_device *dev)
--- /dev/null
+From aaf8a5167291b65e9116cb8736d862965b57c13a Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Fri, 5 Jul 2013 23:39:50 +0200
+Subject: drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit aaf8a5167291b65e9116cb8736d862965b57c13a upstream.
+
+It's not a good idea to also run the pipe_control cleanup.
+
+This regression has been introduced whith the original cs tlb w/a in
+
+commit b45305fce5bb1abec263fcff9d81ebecd6306ede
+Author: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon Dec 17 16:21:27 2012 +0100
+
+ drm/i915: Implement workaround for broken CS tlb on i830/845
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_ringbuffer.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
++++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
+@@ -490,9 +490,6 @@ cleanup_pipe_control(struct intel_ring_b
+ struct pipe_control *pc = ring->private;
+ struct drm_i915_gem_object *obj;
+
+- if (!ring->private)
+- return;
+-
+ obj = pc->obj;
+
+ kunmap(sg_page(obj->pages->sgl));
+@@ -500,7 +497,6 @@ cleanup_pipe_control(struct intel_ring_b
+ drm_gem_object_unreference(&obj->base);
+
+ kfree(pc);
+- ring->private = NULL;
+ }
+
+ static int init_render_ring(struct intel_ring_buffer *ring)
+@@ -571,7 +567,10 @@ static void render_ring_cleanup(struct i
+ if (HAS_BROKEN_CS_TLB(dev))
+ drm_gem_object_unreference(to_gem_object(ring->private));
+
+- cleanup_pipe_control(ring);
++ if (INTEL_INFO(dev)->gen >= 5)
++ cleanup_pipe_control(ring);
++
++ ring->private = NULL;
+ }
+
+ static void
--- /dev/null
+From 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Tue, 9 Jul 2013 09:22:39 +0100
+Subject: drm/i915: Fix write-read race with multiple rings
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 upstream.
+
+Daniel noticed a problem where is we wrote to an object with ring A in
+the middle of a very long running batch, then executed a quick batch on
+ring B before a batch that reads from the same object, its obj->ring would
+now point to ring B, but its last_write_seqno would be still relative to
+ring A. This would allow for the user to read from the object before the
+GPU had completed the write, as set_domain would only check that ring B
+had passed the last_write_seqno.
+
+To fix this simply (and inelegantly), we bump the last_write_seqno when
+switching rings so that the last_write_seqno is always relative to the
+current obj->ring.
+
+This fixes igt/tests/gem_write_read_ring_switch.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+[danvet: Add note about the newly created igt which exercises this bug.]
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -1881,6 +1881,10 @@ i915_gem_object_move_to_active(struct dr
+ u32 seqno = intel_ring_get_seqno(ring);
+
+ BUG_ON(ring == NULL);
++ if (obj->ring != ring && obj->last_write_seqno) {
++ /* Keep the seqno relative to the current ring */
++ obj->last_write_seqno = seqno;
++ }
+ obj->ring = ring;
+
+ /* Add a reference if we're newly entering the active list. */
--- /dev/null
+From e85843bec6c2ea7c10ec61238396891cc2b753a9 Mon Sep 17 00:00:00 2001
+From: Kamal Mostafa <kamal@canonical.com>
+Date: Fri, 19 Jul 2013 15:02:01 -0700
+Subject: drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
+
+From: Kamal Mostafa <kamal@canonical.com>
+
+commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
+BugLink: https://bugs.launchpad.net/bugs/1163720
+BugLink: https://bugs.launchpad.net/bugs/1162026
+
+Some machines suffer from non-functional backlight controls if
+BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so.
+Apply this quirk to Dell XPS 13 models.
+
+Tested-by: Eric Griffith <EGriffith92@gmail.com>
+Tested-by: Kent Baxley <kent.baxley@canonical.com>
+Signed-off-by: Kamal Mostafa <kamal@canonical.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_drv.h | 1 +
+ drivers/gpu/drm/i915/intel_display.c | 16 ++++++++++++++++
+ drivers/gpu/drm/i915/intel_panel.c | 3 ++-
+ 3 files changed, 19 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_drv.h
++++ b/drivers/gpu/drm/i915/i915_drv.h
+@@ -491,6 +491,7 @@ enum intel_sbi_destination {
+ #define QUIRK_PIPEA_FORCE (1<<0)
+ #define QUIRK_LVDS_SSC_DISABLE (1<<1)
+ #define QUIRK_INVERT_BRIGHTNESS (1<<2)
++#define QUIRK_NO_PCH_PWM_ENABLE (1<<3)
+
+ struct intel_fbdev;
+ struct intel_fbc_work;
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -8917,6 +8917,17 @@ static void quirk_invert_brightness(stru
+ DRM_INFO("applying inverted panel brightness quirk\n");
+ }
+
++/*
++ * Some machines (Dell XPS13) suffer broken backlight controls if
++ * BLM_PCH_PWM_ENABLE is set.
++ */
++static void quirk_no_pcm_pwm_enable(struct drm_device *dev)
++{
++ struct drm_i915_private *dev_priv = dev->dev_private;
++ dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE;
++ DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
++}
++
+ struct intel_quirk {
+ int device;
+ int subsystem_vendor;
+@@ -8986,6 +8997,11 @@ static struct intel_quirk intel_quirks[]
+
+ /* Acer Aspire 4736Z */
+ { 0x2a42, 0x1025, 0x0260, quirk_invert_brightness },
++
++ /* Dell XPS13 HD Sandy Bridge */
++ { 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
++ /* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
++ { 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable },
+ };
+
+ static void intel_init_quirks(struct drm_device *dev)
+--- a/drivers/gpu/drm/i915/intel_panel.c
++++ b/drivers/gpu/drm/i915/intel_panel.c
+@@ -354,7 +354,8 @@ void intel_panel_enable_backlight(struct
+ POSTING_READ(reg);
+ I915_WRITE(reg, tmp | BLM_PWM_ENABLE);
+
+- if (HAS_PCH_SPLIT(dev)) {
++ if (HAS_PCH_SPLIT(dev) &&
++ !(dev_priv->quirks & QUIRK_NO_PCH_PWM_ENABLE)) {
+ tmp = I915_READ(BLC_PWM_PCH_CTL1);
+ tmp |= BLM_PCH_PWM_ENABLE;
+ tmp &= ~BLM_PCH_OVERRIDE_ENABLE;
--- /dev/null
+From a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Fri, 19 Jul 2013 20:36:51 +0100
+Subject: drm/i915: Serialize almost all register access
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a upstream.
+
+In theory, the different register blocks were meant to be only ever
+touched when holding either the struct_mutex, mode_config.lock or even a
+specific localised lock. This does not seem to be the case, and the
+hardware reacts extremely badly if we attempt to concurrently access two
+registers within the same cacheline.
+
+The HSD suggests that we only need to do this workaround for display
+range registers. However, upon review we need to serialize the multiple
+stages in our register write functions - if only for preemption
+protection.
+
+Irrespective of the hardware requirements, the current io functions are
+a little too loose with respect to the combination of pre- and
+post-condition testing that we do in conjunction with the actual io. As
+a result, we may be pre-empted and generate both false-postive and
+false-negative errors.
+
+Note well that this is a "90%" solution, there remains a few direct
+users of ioread/iowrite which will be fixed up in the next few patches.
+Since they are more invasive and that this simple change will prevent
+almost all lockups on Haswell, we kept this patch simple to facilitate
+backporting to stable.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_drv.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_drv.c
++++ b/drivers/gpu/drm/i915/i915_drv.c
+@@ -1247,21 +1247,21 @@ hsw_unclaimed_reg_check(struct drm_i915_
+
+ #define __i915_read(x, y) \
+ u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
++ unsigned long irqflags; \
+ u##x val = 0; \
++ spin_lock_irqsave(&dev_priv->gt_lock, irqflags); \
+ if (IS_GEN5(dev_priv->dev)) \
+ ilk_dummy_write(dev_priv); \
+ if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
+- unsigned long irqflags; \
+- spin_lock_irqsave(&dev_priv->gt_lock, irqflags); \
+ if (dev_priv->forcewake_count == 0) \
+ dev_priv->gt.force_wake_get(dev_priv); \
+ val = read##y(dev_priv->regs + reg); \
+ if (dev_priv->forcewake_count == 0) \
+ dev_priv->gt.force_wake_put(dev_priv); \
+- spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags); \
+ } else { \
+ val = read##y(dev_priv->regs + reg); \
+ } \
++ spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags); \
+ trace_i915_reg_rw(false, reg, val, sizeof(val)); \
+ return val; \
+ }
+@@ -1274,8 +1274,10 @@ __i915_read(64, q)
+
+ #define __i915_write(x, y) \
+ void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x val) { \
++ unsigned long irqflags; \
+ u32 __fifo_ret = 0; \
+ trace_i915_reg_rw(true, reg, val, sizeof(val)); \
++ spin_lock_irqsave(&dev_priv->gt_lock, irqflags); \
+ if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
+ __fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
+ } \
+@@ -1287,6 +1289,7 @@ void i915_write##x(struct drm_i915_priva
+ gen6_gt_check_fifodbg(dev_priv); \
+ } \
+ hsw_unclaimed_reg_check(dev_priv, reg); \
++ spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags); \
+ }
+ __i915_write(8, b)
+ __i915_write(16, w)
--- /dev/null
+From 7a7da592cbb22a1d360638dbecc393470c5effe3 Mon Sep 17 00:00:00 2001
+From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
+Date: Tue, 23 Jul 2013 15:49:39 +0200
+Subject: drm/nouveau: fix semaphore dmabuf obj
+
+From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
+
+commit 7a7da592cbb22a1d360638dbecc393470c5effe3 upstream.
+
+Fixes some dmabuf object errors on nv50 chipset and below.
+
+Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
+ drivers/gpu/drm/nouveau/nv50_fence.c | 14 +++++++++-----
+ 2 files changed, 10 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/nv17_fence.c
++++ b/drivers/gpu/drm/nouveau/nv17_fence.c
+@@ -76,7 +76,7 @@ nv17_fence_context_new(struct nouveau_ch
+ struct ttm_mem_reg *mem = &priv->bo->bo.mem;
+ struct nouveau_object *object;
+ u32 start = mem->start * PAGE_SIZE;
+- u32 limit = mem->start + mem->size - 1;
++ u32 limit = start + mem->size - 1;
+ int ret = 0;
+
+ fctx = chan->fence = kzalloc(sizeof(*fctx), GFP_KERNEL);
+--- a/drivers/gpu/drm/nouveau/nv50_fence.c
++++ b/drivers/gpu/drm/nouveau/nv50_fence.c
+@@ -39,6 +39,8 @@ nv50_fence_context_new(struct nouveau_ch
+ struct nv10_fence_chan *fctx;
+ struct ttm_mem_reg *mem = &priv->bo->bo.mem;
+ struct nouveau_object *object;
++ u32 start = mem->start * PAGE_SIZE;
++ u32 limit = start + mem->size - 1;
+ int ret, i;
+
+ fctx = chan->fence = kzalloc(sizeof(*fctx), GFP_KERNEL);
+@@ -51,26 +53,28 @@ nv50_fence_context_new(struct nouveau_ch
+ fctx->base.sync = nv17_fence_sync;
+
+ ret = nouveau_object_new(nv_object(chan->cli), chan->handle,
+- NvSema, 0x0002,
++ NvSema, 0x003d,
+ &(struct nv_dma_class) {
+ .flags = NV_DMA_TARGET_VRAM |
+ NV_DMA_ACCESS_RDWR,
+- .start = mem->start * PAGE_SIZE,
+- .limit = mem->size - 1,
++ .start = start,
++ .limit = limit,
+ }, sizeof(struct nv_dma_class),
+ &object);
+
+ /* dma objects for display sync channel semaphore blocks */
+ for (i = 0; !ret && i < dev->mode_config.num_crtc; i++) {
+ struct nouveau_bo *bo = nv50_display_crtc_sema(dev, i);
++ u32 start = bo->bo.mem.start * PAGE_SIZE;
++ u32 limit = start + bo->bo.mem.size - 1;
+
+ ret = nouveau_object_new(nv_object(chan->cli), chan->handle,
+ NvEvoSema0 + i, 0x003d,
+ &(struct nv_dma_class) {
+ .flags = NV_DMA_TARGET_VRAM |
+ NV_DMA_ACCESS_RDWR,
+- .start = bo->bo.offset,
+- .limit = bo->bo.offset + 0xfff,
++ .start = start,
++ .limit = limit,
+ }, sizeof(struct nv_dma_class),
+ &object);
+ }
--- /dev/null
+From 42a21826dc54583cdb79cc8477732e911ac9c376 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 30 Jul 2013 00:22:53 -0400
+Subject: drm/radeon/atom: initialize more atom interpretor elements to 0
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.
+
+The ProcessAuxChannel table on some rv635 boards assumes
+the divmul members are initialized to 0 otherwise we get
+an invalid fb offset since it has a bad mask set when
+setting the fb base. While here initialize all the
+atom interpretor elements to 0.
+
+Fixes:
+https://bugzilla.kernel.org/show_bug.cgi?id=60639
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/atom.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/atom.c
++++ b/drivers/gpu/drm/radeon/atom.c
+@@ -1222,12 +1222,17 @@ int atom_execute_table(struct atom_conte
+ int r;
+
+ mutex_lock(&ctx->mutex);
++ /* reset data block */
++ ctx->data_block = 0;
+ /* reset reg block */
+ ctx->reg_block = 0;
+ /* reset fb window */
+ ctx->fb_base = 0;
+ /* reset io mode */
+ ctx->io_mode = ATOM_IO_MM;
++ /* reset divmul */
++ ctx->divmul[0] = 0;
++ ctx->divmul[1] = 0;
+ r = atom_execute_table_locked(ctx, index, params);
+ mutex_unlock(&ctx->mutex);
+ return r;
--- /dev/null
+From 7d61d835824f73dc4097b51f800382467c8049c5 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Fri, 26 Jul 2013 13:26:05 -0400
+Subject: drm/radeon: fix audio dto programming on DCE4+
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 7d61d835824f73dc4097b51f800382467c8049c5 upstream.
+
+We need to set the dto source before setting the
+dividers otherwise we may get stability problems
+with the dto leading to audio playback problems.
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/evergreen_hdmi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
++++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
+@@ -157,9 +157,9 @@ static void evergreen_audio_set_dto(stru
+ * number (coefficient of two integer numbers. DCCG_AUDIO_DTOx_PHASE
+ * is the numerator, DCCG_AUDIO_DTOx_MODULE is the denominator
+ */
++ WREG32(DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO0_SOURCE_SEL(radeon_crtc->crtc_id));
+ WREG32(DCCG_AUDIO_DTO0_PHASE, base_rate * 100);
+ WREG32(DCCG_AUDIO_DTO0_MODULE, clock * 100);
+- WREG32(DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO0_SOURCE_SEL(radeon_crtc->crtc_id));
+ }
+
+
--- /dev/null
+From acfec9a5a892f98461f52ed5770de99a3e571ae2 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Sat, 20 Jul 2013 03:13:55 +0400
+Subject: livelock avoidance in sget()
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit acfec9a5a892f98461f52ed5770de99a3e571ae2 upstream.
+
+Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about
+to fail. The superblock is on ->fs_supers, ->s_umount is held exclusive,
+->s_active is 1. Along comes two more processes, trying to mount the same
+thing; sget() in each is picking that superblock, bumping ->s_count and
+trying to grab ->s_umount. ->s_active is 3 now. Original mount(2)
+finally gets to deactivate_locked_super() on failure; ->s_active is 2,
+superblock is still ->fs_supers because shutdown will *not* happen until
+->s_active hits 0. ->s_umount is dropped and now we have two processes
+chasing each other:
+s_active = 2, A acquired ->s_umount, B blocked
+A sees that the damn thing is stillborn, does deactivate_locked_super()
+s_active = 1, A drops ->s_umount, B gets it
+A restarts the search and finds the same superblock. And bumps it ->s_active.
+s_active = 2, B holds ->s_umount, A blocked on trying to get it
+... and we are in the earlier situation with A and B switched places.
+
+The root cause, of course, is that ->s_active should not grow until we'd
+got MS_BORN. Then failing ->mount() will have deactivate_locked_super()
+shut the damn thing down. Fortunately, it's easy to do - the key point
+is that grab_super() is called only for superblocks currently on ->fs_supers,
+so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and
+bump ->s_active; we must never increment ->s_count for superblocks past
+->kill_sb(), but grab_super() is never called for those.
+
+The bug is pretty old; we would've caught it by now, if not for accidental
+exclusion between sget() for block filesystems; the things like cgroup or
+e.g. mtd-based filesystems don't have anything of that sort, so they get
+bitten. The right way to deal with that is obviously to fix sget()...
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/super.c | 25 ++++++++++---------------
+ 1 file changed, 10 insertions(+), 15 deletions(-)
+
+--- a/fs/super.c
++++ b/fs/super.c
+@@ -336,19 +336,19 @@ EXPORT_SYMBOL(deactivate_super);
+ * and want to turn it into a full-blown active reference. grab_super()
+ * is called with sb_lock held and drops it. Returns 1 in case of
+ * success, 0 if we had failed (superblock contents was already dead or
+- * dying when grab_super() had been called).
++ * dying when grab_super() had been called). Note that this is only
++ * called for superblocks not in rundown mode (== ones still on ->fs_supers
++ * of their type), so increment of ->s_count is OK here.
+ */
+ static int grab_super(struct super_block *s) __releases(sb_lock)
+ {
+- if (atomic_inc_not_zero(&s->s_active)) {
+- spin_unlock(&sb_lock);
+- return 1;
+- }
+- /* it's going away */
+ s->s_count++;
+ spin_unlock(&sb_lock);
+- /* wait for it to die */
+ down_write(&s->s_umount);
++ if ((s->s_flags & MS_BORN) && atomic_inc_not_zero(&s->s_active)) {
++ put_super(s);
++ return 1;
++ }
+ up_write(&s->s_umount);
+ put_super(s);
+ return 0;
+@@ -463,11 +463,6 @@ retry:
+ destroy_super(s);
+ s = NULL;
+ }
+- down_write(&old->s_umount);
+- if (unlikely(!(old->s_flags & MS_BORN))) {
+- deactivate_locked_super(old);
+- goto retry;
+- }
+ return old;
+ }
+ }
+@@ -660,10 +655,10 @@ restart:
+ if (hlist_unhashed(&sb->s_instances))
+ continue;
+ if (sb->s_bdev == bdev) {
+- if (grab_super(sb)) /* drops sb_lock */
+- return sb;
+- else
++ if (!grab_super(sb))
+ goto restart;
++ up_write(&sb->s_umount);
++ return sb;
+ }
+ }
+ spin_unlock(&sb_lock);
--- /dev/null
+From 3964acd0dbec123aa0a621973a2a0580034b4788 Mon Sep 17 00:00:00 2001
+From: Oleg Nesterov <oleg@redhat.com>
+Date: Wed, 31 Jul 2013 13:53:28 -0700
+Subject: mm: mempolicy: fix mbind_range() && vma_adjust() interaction
+
+From: Oleg Nesterov <oleg@redhat.com>
+
+commit 3964acd0dbec123aa0a621973a2a0580034b4788 upstream.
+
+vma_adjust() does vma_set_policy(vma, vma_policy(next)) and this
+is doubly wrong:
+
+1. This leaks vma->vm_policy if it is not NULL and not equal to
+ next->vm_policy.
+
+ This can happen if vma_merge() expands "area", not prev (case 8).
+
+2. This sets the wrong policy if vma_merge() joins prev and area,
+ area is the vma the caller needs to update and it still has the
+ old policy.
+
+Revert commit 1444f92c8498 ("mm: merging memory blocks resets
+mempolicy") which introduced these problems.
+
+Change mbind_range() to recheck mpol_equal() after vma_merge() to fix
+the problem that commit tried to address.
+
+Signed-off-by: Oleg Nesterov <oleg@redhat.com>
+Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+Cc: Steven T Hampson <steven.t.hampson@intel.com>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+Cc: Rik van Riel <riel@redhat.com>
+Cc: Andi Kleen <andi@firstfloor.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mempolicy.c | 6 +++++-
+ mm/mmap.c | 2 +-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/mm/mempolicy.c
++++ b/mm/mempolicy.c
+@@ -732,7 +732,10 @@ static int mbind_range(struct mm_struct
+ if (prev) {
+ vma = prev;
+ next = vma->vm_next;
+- continue;
++ if (mpol_equal(vma_policy(vma), new_pol))
++ continue;
++ /* vma_merge() joined vma && vma->next, case 8 */
++ goto replace;
+ }
+ if (vma->vm_start != vmstart) {
+ err = split_vma(vma->vm_mm, vma, vmstart, 1);
+@@ -744,6 +747,7 @@ static int mbind_range(struct mm_struct
+ if (err)
+ goto out;
+ }
++ replace:
+ err = vma_replace_policy(vma, new_pol);
+ if (err)
+ goto out;
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -865,7 +865,7 @@ again: remove_next = 1 + (end > next->
+ if (next->anon_vma)
+ anon_vma_merge(vma, next);
+ mm->map_count--;
+- vma_set_policy(vma, vma_policy(next));
++ mpol_put(vma_policy(next));
+ kmem_cache_free(vm_area_cachep, next);
+ /*
+ * In mprotect's case 6 (see comments on vma_merge),
--- /dev/null
+From c11e5f35ab490bd30591563816fbc83526521777 Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Tue, 9 Jul 2013 16:00:31 -0700
+Subject: Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit c11e5f35ab490bd30591563816fbc83526521777 upstream.
+
+This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for
+IvyBridge CPUs.
+
+The original commit results in repeated 'Timed out waiting for forcewake old
+ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
+with i7-3770K CPU. It ultimately results in a hangup if the system is highly
+loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
+
+Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
+this condition can result in secondary issues.
+
+v2: Only revert patch for Ivybridge CPUs
+ Issue info message if mt forcewake is disabled on Ivybridge
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
+Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Mika Kuoppala <mika.kuoppala@intel.com>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_pm.c | 31 ++++++++++++++++++++++++++++++-
+ 1 file changed, 30 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -4510,9 +4510,38 @@ void intel_gt_init(struct drm_device *de
+ if (IS_VALLEYVIEW(dev)) {
+ dev_priv->gt.force_wake_get = vlv_force_wake_get;
+ dev_priv->gt.force_wake_put = vlv_force_wake_put;
+- } else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
++ } else if (IS_HASWELL(dev)) {
+ dev_priv->gt.force_wake_get = __gen6_gt_force_wake_mt_get;
+ dev_priv->gt.force_wake_put = __gen6_gt_force_wake_mt_put;
++ } else if (IS_IVYBRIDGE(dev)) {
++ u32 ecobus;
++
++ /* IVB configs may use multi-threaded forcewake */
++
++ /* A small trick here - if the bios hasn't configured
++ * MT forcewake, and if the device is in RC6, then
++ * force_wake_mt_get will not wake the device and the
++ * ECOBUS read will return zero. Which will be
++ * (correctly) interpreted by the test below as MT
++ * forcewake being disabled.
++ */
++ mutex_lock(&dev->struct_mutex);
++ __gen6_gt_force_wake_mt_get(dev_priv);
++ ecobus = I915_READ_NOTRACE(ECOBUS);
++ __gen6_gt_force_wake_mt_put(dev_priv);
++ mutex_unlock(&dev->struct_mutex);
++
++ if (ecobus & FORCEWAKE_MT_ENABLE) {
++ dev_priv->gt.force_wake_get =
++ __gen6_gt_force_wake_mt_get;
++ dev_priv->gt.force_wake_put =
++ __gen6_gt_force_wake_mt_put;
++ } else {
++ DRM_INFO("No MT forcewake available on Ivybridge, this can result in issues\n");
++ DRM_INFO("when using vblank-synced partial screen updates.\n");
++ dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get;
++ dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put;
++ }
+ } else if (IS_GEN6(dev)) {
+ dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get;
+ dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put;
--- /dev/null
+From bcfb879432094c267c35a7ff75d953d3a66c193a Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Fri, 28 Jun 2013 09:12:53 -0500
+Subject: rtlwifi: Initialize power-setting callback for USB devices
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit bcfb879432094c267c35a7ff75d953d3a66c193a upstream.
+
+Commit a269913c5 entitled "rtlwifi: Rework rtl_lps_leave() and
+rtl_lps_enter() to use work queue" has two bugs for USB drivers.
+Firstly, the work queue in question was not initialized. Secondly,
+the callback routine used by this queue is contained within the
+file used for PCI devices. As a result, it is not available for
+architectures without PCI hardware.
+
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Reported-by: Richard Genoud <richard.genoud@gmail.com>
+Tested-by: Richard Genoud <richard.genoud@gmail.com>
+Cc: Richard Genoud <richard.genoud@gmail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/rtlwifi/pci.c | 13 -------------
+ drivers/net/wireless/rtlwifi/ps.c | 12 ++++++++++++
+ drivers/net/wireless/rtlwifi/ps.h | 1 +
+ drivers/net/wireless/rtlwifi/usb.c | 2 ++
+ 4 files changed, 15 insertions(+), 13 deletions(-)
+
+--- a/drivers/net/wireless/rtlwifi/pci.c
++++ b/drivers/net/wireless/rtlwifi/pci.c
+@@ -1008,19 +1008,6 @@ static void _rtl_pci_prepare_bcn_tasklet
+ return;
+ }
+
+-static void rtl_lps_change_work_callback(struct work_struct *work)
+-{
+- struct rtl_works *rtlworks =
+- container_of(work, struct rtl_works, lps_change_work);
+- struct ieee80211_hw *hw = rtlworks->hw;
+- struct rtl_priv *rtlpriv = rtl_priv(hw);
+-
+- if (rtlpriv->enter_ps)
+- rtl_lps_enter(hw);
+- else
+- rtl_lps_leave(hw);
+-}
+-
+ static void _rtl_pci_init_trx_var(struct ieee80211_hw *hw)
+ {
+ struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
+--- a/drivers/net/wireless/rtlwifi/ps.c
++++ b/drivers/net/wireless/rtlwifi/ps.c
+@@ -611,6 +611,18 @@ void rtl_swlps_rf_sleep(struct ieee80211
+ MSECS(sleep_intv * mac->vif->bss_conf.beacon_int - 40));
+ }
+
++void rtl_lps_change_work_callback(struct work_struct *work)
++{
++ struct rtl_works *rtlworks =
++ container_of(work, struct rtl_works, lps_change_work);
++ struct ieee80211_hw *hw = rtlworks->hw;
++ struct rtl_priv *rtlpriv = rtl_priv(hw);
++
++ if (rtlpriv->enter_ps)
++ rtl_lps_enter(hw);
++ else
++ rtl_lps_leave(hw);
++}
+
+ void rtl_swlps_wq_callback(void *data)
+ {
+--- a/drivers/net/wireless/rtlwifi/ps.h
++++ b/drivers/net/wireless/rtlwifi/ps.h
+@@ -49,5 +49,6 @@ void rtl_swlps_rf_awake(struct ieee80211
+ void rtl_swlps_rf_sleep(struct ieee80211_hw *hw);
+ void rtl_p2p_ps_cmd(struct ieee80211_hw *hw, u8 p2p_ps_state);
+ void rtl_p2p_info(struct ieee80211_hw *hw, void *data, unsigned int len);
++void rtl_lps_change_work_callback(struct work_struct *work);
+
+ #endif
+--- a/drivers/net/wireless/rtlwifi/usb.c
++++ b/drivers/net/wireless/rtlwifi/usb.c
+@@ -1070,6 +1070,8 @@ int rtl_usb_probe(struct usb_interface *
+ spin_lock_init(&rtlpriv->locks.usb_lock);
+ INIT_WORK(&rtlpriv->works.fill_h2c_cmd,
+ rtl_fill_h2c_cmd_work_callback);
++ INIT_WORK(&rtlpriv->works.lps_change_work,
++ rtl_lps_change_work_callback);
+
+ rtlpriv->usb_data_index = 0;
+ init_completion(&rtlpriv->firmware_loading_complete);
drm-radeon-another-card-with-wrong-primary-dac-adj.patch
drm-radeon-fix-combios-tables-on-older-cards.patch
drm-radeon-improve-dac-adjust-heuristics-for-legacy-pdac.patch
+drm-i915-fix-up-ring-cleanup-for-the-i830-i845-cs-tlb-w-a.patch
+drm-i915-fix-write-read-race-with-multiple-rings.patch
+partially-revert-drm-i915-unconditionally-use-mt-forcewake-on-hsw-ivb.patch
+drm-i915-fix-incoherence-with-fence-updates-on-sandybridge.patch
+drm-i915-fix-long-standing-snb-regression-in-power-consumption-after-resume-v2.patch
+drm-i915-fix-dereferencing-invalid-connectors-in-is_crtc_connector_off.patch
+drm-i915-correctly-restore-fences-with-objects-attached.patch
+drm-i915-quirk-no-pch_pwm_enable-for-dell-xps13-backlight.patch
+drm-i915-serialize-almost-all-register-access.patch
+drm-i915-fix-up-gt-init-sequence-fallout.patch
+drm-i915-fix-missed-hunk-after-gt-access-breakage.patch
+drm-nouveau-fix-semaphore-dmabuf-obj.patch
+drm-radeon-fix-audio-dto-programming-on-dce4.patch
+drm-radeon-atom-initialize-more-atom-interpretor-elements-to-0.patch
+rtlwifi-initialize-power-setting-callback-for-usb-devices.patch
+usb-serial-ftdi_sio-add-more-rt-systems-ftdi-devices.patch
+usb-gadget-udc-core-fix-the-typo-of-udc-state-attribute.patch
+mm-mempolicy-fix-mbind_range-vma_adjust-interaction.patch
+tty_port-fix-refcounting-leak-in-tty_port_tty_hangup.patch
+livelock-avoidance-in-sget.patch
--- /dev/null
+From 1d9e689c934bd5ecb0f273c6c65e0655c5cfee5f Mon Sep 17 00:00:00 2001
+From: Gianluca Anzolin <gianluca@sottospazio.it>
+Date: Thu, 25 Jul 2013 07:26:16 +0200
+Subject: tty_port: Fix refcounting leak in tty_port_tty_hangup()
+
+From: Gianluca Anzolin <gianluca@sottospazio.it>
+
+commit 1d9e689c934bd5ecb0f273c6c65e0655c5cfee5f upstream.
+
+The function tty_port_tty_hangup() could leak a reference to the tty_struct:
+
+ struct tty_struct *tty = tty_port_tty_get(port);
+
+ if (tty && (!check_clocal || !C_CLOCAL(tty))) {
+ tty_hangup(tty);
+ tty_kref_put(tty);
+ }
+
+If tty != NULL and the second condition is false we never call tty_kref_put and
+the reference is leaked.
+
+Fix by always calling tty_kref_put() which accepts a NULL argument.
+
+The patch fixes a regression introduced by commit aa27a094.
+
+Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Signed-off-by: Gianluca Anzolin <gianluca@sottospazio.it>
+Acked-by: Jiri Slaby <jslaby@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/tty_port.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/tty/tty_port.c
++++ b/drivers/tty/tty_port.c
+@@ -256,10 +256,9 @@ void tty_port_tty_hangup(struct tty_port
+ {
+ struct tty_struct *tty = tty_port_tty_get(port);
+
+- if (tty && (!check_clocal || !C_CLOCAL(tty))) {
++ if (tty && (!check_clocal || !C_CLOCAL(tty)))
+ tty_hangup(tty);
+- tty_kref_put(tty);
+- }
++ tty_kref_put(tty);
+ }
+ EXPORT_SYMBOL_GPL(tty_port_tty_hangup);
+
--- /dev/null
+From 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 Mon Sep 17 00:00:00 2001
+From: Rong Wang <Rong.Wang@csr.com>
+Date: Sun, 28 Jul 2013 23:01:35 +0800
+Subject: usb: gadget: udc-core: fix the typo of udc state attribute
+
+From: Rong Wang <Rong.Wang@csr.com>
+
+commit 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 upstream.
+
+The name of udc state attribute file under sysfs is registered as
+"state", while usb_gadget_set_state take it as "status" when it's
+going to update. This patch fixes the typo.
+
+Signed-off-by: Rong Wang <Rong.Wang@csr.com>
+Signed-off-by: Barry Song <Baohua.Song@csr.com>
+Signed-off-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/udc-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/gadget/udc-core.c
++++ b/drivers/usb/gadget/udc-core.c
+@@ -105,7 +105,7 @@ void usb_gadget_set_state(struct usb_gad
+ enum usb_device_state state)
+ {
+ gadget->state = state;
+- sysfs_notify(&gadget->dev.kobj, NULL, "status");
++ sysfs_notify(&gadget->dev.kobj, NULL, "state");
+ }
+ EXPORT_SYMBOL_GPL(usb_gadget_set_state);
+
--- /dev/null
+From fed1f1ed90bce42ea010e2904cbc04e7b8304940 Mon Sep 17 00:00:00 2001
+From: "Rick Farina (Zero_Chaos)" <zerochaos@gentoo.org>
+Date: Mon, 29 Jul 2013 15:17:59 -0400
+Subject: USB: serial: ftdi_sio: add more RT Systems ftdi devices
+
+From: "Rick Farina (Zero_Chaos)" <zerochaos@gentoo.org>
+
+commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream.
+
+RT Systems makes many usb serial cables based on the ftdi_sio driver for
+programming various amateur radios. This patch is a full listing of
+their current product offerings and should allow these cables to all
+be recognized.
+
+Signed-off-by: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/ftdi_sio.c | 31 ++++++++++++++++++++++++++++---
+ drivers/usb/serial/ftdi_sio_ids.h | 34 +++++++++++++++++++++++++++++-----
+ 2 files changed, 57 insertions(+), 8 deletions(-)
+
+--- a/drivers/usb/serial/ftdi_sio.c
++++ b/drivers/usb/serial/ftdi_sio.c
+@@ -735,9 +735,34 @@ static struct usb_device_id id_table_com
+ { USB_DEVICE(FTDI_VID, FTDI_NDI_AURORA_SCU_PID),
+ .driver_info = (kernel_ulong_t)&ftdi_NDI_device_quirk },
+ { USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) },
+- { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_SERIAL_VX7_PID) },
+- { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_CT29B_PID) },
+- { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_RTS01_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S03_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_59_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57A_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57B_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29A_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29B_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29F_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_62B_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S01_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_63_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29C_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_81B_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_82B_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K5D_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K4Y_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K5G_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S05_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_60_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_61_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_62_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_63B_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_64_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_65_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_92_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_92D_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_W5R_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_A5R_PID) },
++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_PW1_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_MAXSTREAM_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_PHI_FISCO_PID) },
+ { USB_DEVICE(TML_VID, TML_USB_SERIAL_PID) },
+--- a/drivers/usb/serial/ftdi_sio_ids.h
++++ b/drivers/usb/serial/ftdi_sio_ids.h
+@@ -815,11 +815,35 @@
+ /*
+ * RT Systems programming cables for various ham radios
+ */
+-#define RTSYSTEMS_VID 0x2100 /* Vendor ID */
+-#define RTSYSTEMS_SERIAL_VX7_PID 0x9e52 /* Serial converter for VX-7 Radios using FT232RL */
+-#define RTSYSTEMS_CT29B_PID 0x9e54 /* CT29B Radio Cable */
+-#define RTSYSTEMS_RTS01_PID 0x9e57 /* USB-RTS01 Radio Cable */
+-
++#define RTSYSTEMS_VID 0x2100 /* Vendor ID */
++#define RTSYSTEMS_USB_S03_PID 0x9001 /* RTS-03 USB to Serial Adapter */
++#define RTSYSTEMS_USB_59_PID 0x9e50 /* USB-59 USB to 8 pin plug */
++#define RTSYSTEMS_USB_57A_PID 0x9e51 /* USB-57A USB to 4pin 3.5mm plug */
++#define RTSYSTEMS_USB_57B_PID 0x9e52 /* USB-57B USB to extended 4pin 3.5mm plug */
++#define RTSYSTEMS_USB_29A_PID 0x9e53 /* USB-29A USB to 3.5mm stereo plug */
++#define RTSYSTEMS_USB_29B_PID 0x9e54 /* USB-29B USB to 6 pin mini din */
++#define RTSYSTEMS_USB_29F_PID 0x9e55 /* USB-29F USB to 6 pin modular plug */
++#define RTSYSTEMS_USB_62B_PID 0x9e56 /* USB-62B USB to 8 pin mini din plug*/
++#define RTSYSTEMS_USB_S01_PID 0x9e57 /* USB-RTS01 USB to 3.5 mm stereo plug*/
++#define RTSYSTEMS_USB_63_PID 0x9e58 /* USB-63 USB to 9 pin female*/
++#define RTSYSTEMS_USB_29C_PID 0x9e59 /* USB-29C USB to 4 pin modular plug*/
++#define RTSYSTEMS_USB_81B_PID 0x9e5A /* USB-81 USB to 8 pin mini din plug*/
++#define RTSYSTEMS_USB_82B_PID 0x9e5B /* USB-82 USB to 2.5 mm stereo plug*/
++#define RTSYSTEMS_USB_K5D_PID 0x9e5C /* USB-K5D USB to 8 pin modular plug*/
++#define RTSYSTEMS_USB_K4Y_PID 0x9e5D /* USB-K4Y USB to 2.5/3.5 mm plugs*/
++#define RTSYSTEMS_USB_K5G_PID 0x9e5E /* USB-K5G USB to 8 pin modular plug*/
++#define RTSYSTEMS_USB_S05_PID 0x9e5F /* USB-RTS05 USB to 2.5 mm stereo plug*/
++#define RTSYSTEMS_USB_60_PID 0x9e60 /* USB-60 USB to 6 pin din*/
++#define RTSYSTEMS_USB_61_PID 0x9e61 /* USB-61 USB to 6 pin mini din*/
++#define RTSYSTEMS_USB_62_PID 0x9e62 /* USB-62 USB to 8 pin mini din*/
++#define RTSYSTEMS_USB_63B_PID 0x9e63 /* USB-63 USB to 9 pin female*/
++#define RTSYSTEMS_USB_64_PID 0x9e64 /* USB-64 USB to 9 pin male*/
++#define RTSYSTEMS_USB_65_PID 0x9e65 /* USB-65 USB to 9 pin female null modem*/
++#define RTSYSTEMS_USB_92_PID 0x9e66 /* USB-92 USB to 12 pin plug*/
++#define RTSYSTEMS_USB_92D_PID 0x9e67 /* USB-92D USB to 12 pin plug data*/
++#define RTSYSTEMS_USB_W5R_PID 0x9e68 /* USB-W5R USB to 8 pin modular plug*/
++#define RTSYSTEMS_USB_A5R_PID 0x9e69 /* USB-A5R USB to 8 pin modular plug*/
++#define RTSYSTEMS_USB_PW1_PID 0x9e6A /* USB-PW1 USB to 8 pin modular plug*/
+
+ /*
+ * Physik Instrumente
projects / thirdparty / kernel / stable-queue.git / commitdiff
