linux-kernel - Re: [git pull] Input updates 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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.2.00.1005270956380.3689@i5.linux-foundation.org>
Date:	Thu, 27 May 2010 10:06:37 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Robert Hancock <hancockrwd@...il.com>
cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, Bastien Nocera <hadess@...ess.net>
Subject: Re: [git pull] Input updates for 2.6.34-rc6

On Thu, 27 May 2010, Robert Hancock wrote:
> 
> I don't think they did anything wrong in their BIOS, it's working exactly as
> the spec intended. There is no PS/2 controller, and the ACPI PnP tables do not
> list one.

You seem to be unable to read. 

First off, there _is_ a PS2 controller. You can't get any normal Intel 
chips without one, as far as I can tell. The lines may not be brought out, 
but that's immaterial.

Secondly, even if there wasn't any - or the controller is actively 
disabled, Linux handles that situation perfectly fine. The fact is, the 
low ports (< 0x100) are reserved for motherboard devices, and Linux probes 
the things fine.

Thirdly, the thing is, PnP tables are incomplete. Always. They don't prove 
a negative. Deal with it. It's a _fact_.

So Apple must have actively screwed things up. If you can't admit that, 
it's your problem.

> Long and the short of it is, it seems pretty safe to say that on any ACPI
> machine, if there's no PnP entry for PS/2 devices, the BIOS does not intend
> for the OS to use them. 

And your argument is pure and utter sh*t. I don't know why I even bother 
replying to it, but I'll try one more time:

 - BIOS writers are incompetent drug-addled morons. Your argument that 
   "the BIOS does not intend for the OS to use them" is a totally idiotic 
   argument, for the simple reason that it's not up to the BIOS writers, 
   and even if it _was_ up to them, they always screw things up.

The thing boils down to: we cannot trust the firmware anyway (this is a 
simple _fact_, not some random opinion), and no, the BIOS writers do not 
have some magic powers that allow them to determine how hardware should be 
used.

Should we always use PIO mode for IDE just because the BIOS may have set 
it up that way? Even if we know better? It's the exact same issue: 
firmware simply isn't the last word. It shouldn't be in the first place, 
but more importantly, it _cannot_ be, because the BIOS writers have shown 
themselves to be inevitably incompetent.

And Apple BIOS writers seem to be worse than average. The _average_ BIOS 
writer tends to still result in working keyboards (or properly disabled 
ones). The incompetent ones do bad things with SMM and actively break the 
keyboard. Apple is not alone in this, although I think this is the first 
time I hear of somebody breaking it quite _that_ badly (normally it's just 
"horribly bad latency due to SMM traps").

		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/