Message-ID: <AANLkTimkI2rLOO2vaPFBQUbzr5t0pAQGQ5R5noTOBp4K@mail.gmail.com>
Date:	Thu, 27 May 2010 17:03:08 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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, May 27, 2010 at 11:06 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> 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.

I believe the PS/2 controller is normally on the LPC SuperIO chip, not
the chipset itself. It's entirely possible that Apple used a chip that
didn't include any such controller at all. It's also possible they
reused the IO ports normally assigned to it for something else (which
would be a questionable decision, yes), which is why the machine blows
up when the ports get probed.

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

It's highly unlikely that they are incomplete in this respect, as
since I mentioned, Windows would fail to recognize the PS/2 controller
that people would expect to work, which would most likely get
noticed..

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

I think this is a case where it has to be trusted, because that's what
Windows does. Experience has shown time and again that deviating from
Windows behavior with these kinds of ACPI platform-related issues is
fraught with problems, since hardware vendors test only with Windows.
If Linux behaved the same as Windows here, and left the PS/2 IO ports
alone since there was no PNP device defined for it, this problem
presumably wouldn't have come up.

Since many machines are moving towards no longer including legacy PS/2
ports, this kind of thing seems likely to come up elsewhere..
--
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/

Powered by blists - more mailing lists