linux-kernel - [PATCH 3.8 059/166] drm/i915: Do not clobber config status after a forced restore of hw state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jan 2014 13:51:13 -0800
From:	Kamal Mostafa <kamal@...onical.com>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	kernel-team@...ts.ubuntu.com
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	Daniel Vetter <daniel@...ll.ch>,
	Paulo Zanoni <paulo.r.zanoni@...el.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Kamal Mostafa <kamal@...onical.com>
Subject: [PATCH 3.8 059/166] drm/i915: Do not clobber config status after a forced restore of hw state

3.8.13.16 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Chris Wilson <chris@...is-wilson.co.uk>

commit edd5b13313551d6b04acfb90d3db58ed3cf3c814 upstream.

We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial connector statuses and prepares the
hardware for a thorough probing. However, during a lid event, we only
want to undo the damage caused by the bios by resetting our last known
mode. In this cirumstance, we do not want to clobber our desired state.

In order to try and keep sanity between the config state and our own
tracking, do the drm_mode_config_reset() first along the load/resume
paths before reading out the hw state and apply any definite known
corrections.

v2: "As discussed on irc I don't think we should force the connector
state to anything here: Imo connector->status should reflect what we
believe to be the true output connection state, whereas connector->encoder
reflects whether this connector is wired up to a pipe. And since we no
longer reject modeset on disconnected connectors and never nuked the pipe
if the connector gets disconnected there's no reason for that - such policy
is userspace's job.

This regression has been introduced in

commit 2e9388923e83bc4e2726f170a984621f1d582e77
Author: Daniel Vetter <daniel.vetter@...ll.ch>
Date:   Thu Oct 11 20:08:24 2012 +0200

    drm/i915/crt: explicitly set up HOTPLUG_BITS on resume"
so sayeth Daniel.

Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
Cc: Daniel Vetter <daniel@...ll.ch>
Cc: Paulo Zanoni <paulo.r.zanoni@...el.com>
Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa <kamal@...onical.com>
---
 drivers/gpu/drm/i915/i915_drv.c      | 1 +
 drivers/gpu/drm/i915/intel_display.c | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a749aca..bfa8910 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -590,6 +590,7 @@ static int __i915_drm_thaw(struct drm_device *dev)
 		mutex_unlock(&dev->struct_mutex);

 		intel_modeset_init_hw(dev);
+		drm_mode_config_reset(dev);
 		intel_modeset_setup_hw_state(dev, false);
 		drm_irq_install(dev);
 	}
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 82fcb37..5b769a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9357,8 +9357,6 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
 	}

 	intel_modeset_check_state(dev);
-
-	drm_mode_config_reset(dev);
 }

 void intel_modeset_gem_init(struct drm_device *dev)
@@ -9367,6 +9365,7 @@ void intel_modeset_gem_init(struct drm_device *dev)

 	intel_setup_overlay(dev);

+	drm_mode_config_reset(dev);
 	intel_modeset_setup_hw_state(dev, false);
 }

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/