From: Linus Torvalds <torvalds@linux-foundation.org>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-input@vger.kernel.org, Bastien Nocera <hadess@hadess.net>
Subject: Re: [git pull] Input updates for 2.6.34-rc6
Date: Thu, 27 May 2010 10:06:37 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1005270956380.3689@i5.linux-foundation.org> (raw)
In-Reply-To: <4BFE0FAB.9040009@gmail.com>
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
next prev parent reply other threads:[~2010-05-27 17:10 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-13 7:57 Dmitry Torokhov
2010-05-13 14:35 ` Linus Torvalds
2010-05-13 14:47 ` Bastien Nocera
2010-05-13 15:04 ` Linus Torvalds
2010-05-13 15:19 ` Linus Torvalds
2010-05-13 15:50 ` Dmitry Torokhov
2010-05-13 16:16 ` Linus Torvalds
2010-05-13 16:38 ` Randy Dunlap
2010-05-13 20:15 ` Matthew Garrett
2010-05-13 16:01 ` Dmitry Torokhov
2010-05-13 16:54 ` Linus Torvalds
2010-05-13 16:58 ` Linus Torvalds
2010-05-13 17:16 ` Dmitry Torokhov
2010-05-13 17:30 ` Linus Torvalds
2010-05-13 18:10 ` Dmitry Torokhov
2010-05-13 19:55 ` Linus Torvalds
2010-05-14 7:56 ` Eric W. Biederman
2010-05-14 14:54 ` Linus Torvalds
2010-05-14 15:38 ` Matthew Garrett
2010-05-14 15:42 ` Linus Torvalds
2010-05-14 15:49 ` Matthew Garrett
2010-05-20 4:53 ` Len Brown
[not found] ` <alpine.LFD.2.00.1005131232350.3711@i5.linux-foundation.org>
2010-05-13 21:05 ` Dmitry Torokhov
2010-05-13 21:21 ` Linus Torvalds
2010-05-13 23:39 ` Matthew Garrett
2010-05-20 4:56 ` Len Brown
2010-05-20 7:08 ` Dmitry Torokhov
2010-05-27 6:22 ` Robert Hancock
2010-05-27 6:43 ` Dmitry Torokhov
2010-05-27 17:06 ` Linus Torvalds [this message]
2010-05-27 23:03 ` Robert Hancock
2010-05-28 0:46 ` Linus Torvalds
2010-05-28 1:03 ` Dmitry Torokhov
2010-05-28 4:05 ` Robert Hancock
2010-05-28 5:10 ` Dmitry Torokhov
2010-05-14 14:55 ` Matthew Garrett
2010-05-14 15:16 ` Linus Torvalds
2010-05-14 16:28 ` Dmitry Torokhov
2010-05-14 18:47 ` david
2010-05-14 18:49 ` Matthew Garrett
2010-05-14 18:55 ` david
2010-05-14 18:59 ` Matthew Garrett
2010-05-14 19:05 ` david
2010-05-28 2:38 ` Mike Frysinger
2010-08-04 6:20 ` Dmitry Torokhov
2010-08-04 6:29 ` Dmitry Torokhov
2010-05-14 16:29 ` Dmitry Torokhov
2010-05-14 16:35 ` Matthew Garrett
-- strict thread matches above, loose matches on Subject: below --
2010-05-05 6:41 Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.1005270956380.3689@i5.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=hadess@hadess.net \
--cc=hancockrwd@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®