linux-kernel - Re: [git pull request] ACPI patches for 2.6.34-rc6

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, 6 May 2010 19:34:10 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Len Brown <lenb@...nel.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull request] ACPI patches for 2.6.34-rc6

On Thu, 6 May 2010, Len Brown wrote:
> 
> The big DMI list in sleep.c a temporary brute force and low-risk workaround.
> We will endeavor to delete it entirely in 2.6.35 with a clean fix
> that was deemed too risky for this late in the .34 release cycle.

Btw, why don't we just force the SCI_EN by hand?

We did that for the Apple Mac Mini bug too. It was always the right thing 
to do.

There is _no_ reason not to force it. If the BIOS set it, it's a no-op. If 
the BIOS didn't set it, it's a bug that _must_ be fixed.

I really don't see the reason for that DMI list. What could _possibly_ go 
wrong for just setting the damn bit that we _know_ has to be set?

How could setting SCI_EN _ever_ be a bug? Seriously? Why are we doing this 
conditionally, especially considering that even the commit message here 
explicitly states that Windows does it unconditionally?

And no, I'm not interested in "that toilet paper spec says you can't touch 
it". I care about _reality_.

				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/