Prev: HWPOISON for hugepage (v5)
Next: gta02: Use pcf50633 backlight driver instead of platform backlight driver.
From: Robert Hancock on 27 May 2010 02:30
On 05/13/2010 10:54 AM, Linus Torvalds wrote:
>
>
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
>>
>> Apple does proper thing in BIOS and omits keyboard and mouse PNP
>> devices, but because of other players we do not really trust PNP BIOS
>> and resort to banding on ports directly - there are cases when box has
>> mouse and/or keyboard but they are not present in BIOS. Damed if you do,
>> damned if you don't...
>
> Umm. No.
>
> PnP information _commonly_ doesn't inclure PS/2 ports, even when they
> exist. Lack of PnP information about the keyboard port means absolutely
> nothing, and anybody who tells you otherwise is totally and utterly wrong.
>
> So don't confuse this with PnP issues. That's a total red herring, and
> Apple is _not_at_all_ "doing the proper thing in the BIOS".
>
> Quite the reverse. Apple is very clearly doing something horribly _wrong_
> in their BIOS. Don't give them kudos for being incompetent morons.

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. I wouldn't argue that it was a good decision
of them to have the hardware somehow blow up if something poked those
ports anyway, but from a BIOS point of view they did the right thing.

>
> Just google for
>
> "Probing ports directly" "i8042 KBD port"
>
> and you'll get a lot of hits. That's not because those machines have wrong
> PnP tables - it's because fundamentally PNP is a joke, and on PC's what is
> much more important is "standard IO ports".
>
> For example, in that thread, Bastien is quoted:
>
> > In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> > controller exists, we randomly bang on the ports in the expectation
> > they'll be there anyway. This seems rather misguided.
>
> and all that tells me is that Bastien doesn't know what he is doing. It is
> _not_ "randomly bang" - it's called standard PC hardware. And it's not
> "misguided" - it's very much correct and required, exactly because PnP
> itself is the misguided aborted fetus of a braindamaged mind.

I think that may have been me, actually, not Bastien. Misguided may have
been a too strong term, but in this case I think the PnP information is
quite trustable because Windows trusts it. Definitely for the PS/2 mouse
controller (quite likely the keyboard too), if Windows is in ACPI mode
and the PnP tables do not list it, it will not detect or use it.

Now, many BIOSes seem to have have code (like an "auto" mode for the
PS/2 port, which may or may not be always set) which disables the PnP
entry if it doesn't detect a mouse or keyboard connected on boot. If
memory serves, this is because I think at least on some versions, if
Windows finds a controller but no mouse is responding then it shows up
with an error indication in Device Manager, which tends to make people
unhappy. This is likely what's responsible for most of those cases where
Linux detects devices after "probing ports directly", because the BIOS
hid the device but we were too "clever" for it and found it anyway.

In fact on a lot of boards, Linux still detects the port even if set as
"disabled" in the BIOS, because all that does is disable the PnP entry.

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. There may be cases where you might
want to try to locate ports anyway (maybe you really want to hotplug a
mouse in after boot, or you have an ancient KVM which doesn't emulate a
device presence on the non-selected machine), but those seem like very
much the exception rather than the rule.

>
> We do not trust BIOS tables, because BIOS writers are invariably totally
> incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS
> writers. QED. And in fact the Apple problem is an _example_ of this BIOS
> writer incompetence, not some shining example of them doing something
> right.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 27 May 2010 02:50
On Thu, May 27, 2010 at 12:22:35AM -0600, Robert Hancock wrote:
> On 05/13/2010 10:54 AM, Linus Torvalds wrote:
> >
> >
> >On Thu, 13 May 2010, Dmitry Torokhov wrote:
> >>
> >>Apple does proper thing in BIOS and omits keyboard and mouse PNP
> >>devices, but because of other players we do not really trust PNP BIOS
> >>and resort to banding on ports directly - there are cases when box has
> >>mouse and/or keyboard but they are not present in BIOS. Damed if you do,
> >>damned if you don't...
> >
> >Umm. No.
> >
> >PnP information _commonly_ doesn't inclure PS/2 ports, even when they
> >exist. Lack of PnP information about the keyboard port means absolutely
> >nothing, and anybody who tells you otherwise is totally and utterly wrong.
> >
> >So don't confuse this with PnP issues. That's a total red herring, and
> >Apple is _not_at_all_ "doing the proper thing in the BIOS".
> >
> >Quite the reverse. Apple is very clearly doing something horribly _wrong_
> >in their BIOS. Don't give them kudos for being incompetent morons.
>
> 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. I wouldn't argue that it was a good
> decision of them to have the hardware somehow blow up if something
> poked those ports anyway, but from a BIOS point of view they did the
> right thing.
>
> >
> >Just google for
> >
> > "Probing ports directly" "i8042 KBD port"
> >
> >and you'll get a lot of hits. That's not because those machines have wrong
> >PnP tables - it's because fundamentally PNP is a joke, and on PC's what is
> >much more important is "standard IO ports".
> >
> >For example, in that thread, Bastien is quoted:
> >
> > > In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> > > controller exists, we randomly bang on the ports in the expectation
> > > they'll be there anyway. This seems rather misguided.
> >
> >and all that tells me is that Bastien doesn't know what he is doing. It is
> >_not_ "randomly bang" - it's called standard PC hardware. And it's not
> >"misguided" - it's very much correct and required, exactly because PnP
> >itself is the misguided aborted fetus of a braindamaged mind.
>
> I think that may have been me, actually, not Bastien. Misguided may
> have been a too strong term, but in this case I think the PnP
> information is quite trustable because Windows trusts it. Definitely
> for the PS/2 mouse controller (quite likely the keyboard too), if
> Windows is in ACPI mode and the PnP tables do not list it, it will
> not detect or use it.
>
> Now, many BIOSes seem to have have code (like an "auto" mode for the
> PS/2 port, which may or may not be always set) which disables the
> PnP entry if it doesn't detect a mouse or keyboard connected on
> boot. If memory serves, this is because I think at least on some
> versions, if Windows finds a controller but no mouse is responding
> then it shows up with an error indication in Device Manager, which
> tends to make people unhappy. This is likely what's responsible for
> most of those cases where Linux detects devices after "probing ports
> directly", because the BIOS hid the device but we were too "clever"
> for it and found it anyway.
>
> In fact on a lot of boards, Linux still detects the port even if set
> as "disabled" in the BIOS, because all that does is disable the PnP
> entry.
>
> 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. There may be cases where you
> might want to try to locate ports anyway (maybe you really want to
> hotplug a mouse in after boot, or you have an ancient KVM which
> doesn't emulate a device presence on the non-selected machine), but
> those seem like very much the exception rather than the rule.
>

I would be much more happy if ACPI would add devices to the device tree
even if they happen to be disabled. Then we could really trust DSDTs and
not bang i8042 ports if the controller is truly not there (newer Dell
servers, Apple, etc) but still woudl detect the controller just fine if
BIOS decided to hide it from Windows.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 27 May 2010 13:20


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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 27 May 2010 19:10
On Thu, May 27, 2010 at 11:06 AM, Linus Torvalds
<torvalds(a)linux-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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 27 May 2010 21:00


On Thu, 27 May 2010, Robert Hancock wrote:
>
> 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..

Did you miss the part where I actually quoted my own modern Core i5
machine that _does_ have a keyboard controller, and _does_ have a keyboard
port, and that does _not_ mention them in the PnP tables?

> I think this is a case where it has to be trusted, because that's what
> Windows does.

The thing is, Windows isn't used for things like headless machines. Which
we went over extensively in the thread. There's a _reason_ why Linux
probes the dang thing.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: HWPOISON for hugepage (v5)
Next: gta02: Use pcf50633 backlight driver instead of platform backlight driver.