linux-kernel - Re: [git pull] drm fixes

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:	Thu, 23 Dec 2010 08:51:06 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	Takashi Iwai <tiwai@...e.de>, linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

On Wed, 22 Dec 2010 19:54:31 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> >                         The Lenovo U160's or the
> > Sandybridge SDV? And why does it work for that other OS? <Insert
> > rhetorical question of the day here.>
> 
> Quite frankly, I don't think the question should *ever* be "whose BIOS
> is wrong?"
> 
> You should always take for granted that the BIOS is wrong. It's not a
> question of "blame the BIOS", it's a question of facts of life.
> 
> It's 100% pointless to point fingers and say "the HP BIOS is wrong" or
> "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that
> relies on the BIOS to such a degree that it either works or not based
> on it is by definition broken.
> 
> Why does that code need to figure out some LVDS clock from the BIOS?
> Why can't the code look at the actual hardware state or similar, since
> presumably the screen is on after boot. THAT we can rely on, since a
> BIOS that doesn't initialize LVDS is not going to ever ship even as
> pre-release.

Oh I wish we could just do that.  Strictly speaking though this isn't
so much of a BIOS issue as it is a ROM issue.  Platform vendors provide
no way of getting at platform configuration details related to graphics
aside from the tables they flash into ROM along with the VBIOS.  The
tables are just like an EDID ROM on a display: they communicate data we
have no other way of getting.

In the particular case of SSC, there's a board down spread spectrum
clock reference source at a fixed frequency.  We can't automatically
determine it at runtime (asking the user "can you see this" at boot
time isn't really an option), so we need to rely on the VBT to tell
us.  The Windows driver uses this data as well, but obviously either
it's incorrect on our SDV (possible) or we're failing to parse the data
correctly (likely).  It's also possible we're failing to look at a bit
that says "use/don't use SSC on this platform" making the frequency
field meaningless.

We'll figure it out or disable SSC enabling altogether failing that
(risking interference with other components like wireless and sound).

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/