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

Message-ID: <AANLkTikwQNim-hcTm7Wn7pzUnVkfG6=9JCKNMRyM0rmm@mail.gmail.com>
Date:	Thu, 23 Dec 2010 09:48:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alex Riesen <raa.lkml@...il.com>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	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 Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen <raa.lkml@...il.com> wrote:
> On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> 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.
>
> What if the system booted with it's display turned off? Like a closed
> laptop lid or disconnected monitor?

So then we might have to guess and even use the BIOS state for guessing.

But what's so hard to understand about that word "guess"? That really
is what happens every single time you use some BIOS table. It's not
"look up". It's not "get the right data". It very much is all about
"guessing". The BIOS tables are invariably buggy, and have likely only
ever been tested with one particular version of Windows.

And that's _especially_ true of something like VBIOS tables. They
haven't been tested even with windows, they have only been tested with
the particular graphics driver that the vendor shipped with that
machine. It's quite possible - even likely - that the graphics driver
hard-codes something.

So think about it - if we boot with the laptop open, you have two
choices: "ask the hardware for real working state" or "guess by
probing random state from the BIOS that may or may not actually ever
be used that way by anything".

Which choice would you pick?

And if that means that some laptops have to be booted with the lid
open, that really isn't a problem.

And yes, I do realize that VGA traditionally has had lots of hardware
state that is write-only and cannot be read back. It's possible that
this case is one of those. I dunno. I hope not.

(Side note: resume is different from boot. You should test that resume
works with the lid closed, because resume state is not at all
guaranteed to be sane at all, lid or no lid. But the way to fix that
is NOT to ask the BIOS, it's to remember the state from the original
boot from before the suspend).

                                  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/