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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 22 Dec 2010 19:54:31 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	Takashi Iwai <tiwai@...e.de>, Dave Airlie <airlied@...ux.ie>,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] drm fixes

On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai <tiwai@...e.de> wrote:
>> The commit 448f53a1ede54eb854d036abf54573281412d650
>>   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>>
>> causes a regression on a SandyBridge machine here.
>> The laptop display (LVDS) becomes blank.  Reverting the commit fixes
>> the problem.
>
> The question is whose BIOS is wrong?

I don't think so.

>                         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.

                        Linus
--
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/