[lkml]   [2010]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [git pull] Input updates for 2.6.34-rc6
    On Thu, May 27, 2010 at 11:06 AM, Linus Torvalds
    <> 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

    > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-05-28 01:05    [W:0.041 / U:2.220 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site