linux-kernel - Re: [PATCH v2] drm/i915: ignore pipe select bit when checking for LVDS register initialization

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] [day] [month] [year] [list]

Message-ID: <20120614095617.GA4797@phenom.ffwll.local>
Date:	Thu, 14 Jun 2012 11:56:17 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] drm/i915: ignore pipe select bit when checking for
 LVDS register initialization

On Wed, Jun 13, 2012 at 03:26:00PM -0500, Seth Forshee wrote:
> On Wed, Jun 13, 2012 at 09:46:15PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 13, 2012 at 01:46:58PM -0500, Seth Forshee wrote:
> > > The Lenovo Thinkpad T410 has the LVDS_PIPEB_SELECT bit set in the LVDS
> > > register when booted with the lid closed, even though the LVDS hasn't
> > > really been initialized. Ignore this bit so that the VBT value will be
> > > used instead.
> > > 
> > > Signed-off-by: Seth Forshee <seth.forshee@...onical.com>
> > Queued for -next, thanks for the patch. Chris had some reservations about
> > the sanity of this patch, but given that it works around bios-insanity I'm
> > gonna just take this chance to stab myself with lvds-machines blowing up
> > left and right ;-)
> 
> Let's hope that doesn't happen ;)
> 
> I do find myself wondering though whether it might be better to prefer
> the value from the VBT whenever there's one available, and only rely on
> the actual register value as a fallback, since the bios can't be trusted
> to initialize the register. I'm pretty ignorant about all this graphics
> stuff though; I assume there's a reason it isn't done this way?

The usual reasoning is that if it's in the register, it's the value that
makes something show up on the screen and hence has a higher change of
being right. Yep, BIOS routinely store total garbage in vbt (or the newer
OpRegion) and somehow fix that up when copying things to the hw :(
Obviously there's also the other case where the hw values aren't set up,
in which case we try to try to fall back to vbt values.
-Daniel
-- 
Daniel Vetter
Mail: daniel@...ll.ch
Mobile: +41 (0)79 365 57 48
--
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/