lkml.org 
[lkml]   [2010]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [git pull] Input updates for 2.6.34-rc6
    From
    On Thu, May 27, 2010 at 11:06 AM, Linus Torvalds
    <torvalds@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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-05-28 01:05    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean