Re: [PATCH] Disable i8042 checks on Intel Apple Macs

[Robert Hancock]

On Thu, Jan 21, 2010 at 3:49 PM, Justin P. Mattock
<justinmattock@xxxxxxxxx> wrote:
> On 01/21/10 13:39, Robert Hancock wrote:
>>
>> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
>> <dmitry.torokhov@xxxxxxxxx>  wrote:
>>>
>>> On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
>>>>
>>>> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
>>>>>
>>>>> As those computers never had any i8042 controllers, and the
>>>>> current lookup code could potentially lock up/hang/wait for
>>>>> timeout for long periods of time.
>>>>>
>>>>> Fixes intermittent hangs on boot on a MacbookAir1,1
>>>>>
>>>>> Signed-off-by: Bastien Nocera<hadess@xxxxxxxxxx>
>>>>
>>>> I assume this is happening because of this code in
>>>> drivers/input/serio/i8042-x86ia64io.h:
>>>>
>>>>         if (!i8042_pnp_kbd_devices&&  !i8042_pnp_aux_devices) {
>>>>                 i8042_pnp_exit();
>>>> #if defined(__ia64__)
>>>>                 return -ENODEV;
>>>> #else
>>>>                 printk(KERN_INFO "PNP: No PS/2 controller found.
>>>> Probing ports directly.\n");
>>>>                 return 0;
>>>> #endif
>>>>
>>>> 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.
>>>
>>> Basically, we do not trust BIOS writers on x86 ;) In the past there were
>>> occasions when they forgot to mention presence of KBD/AUX in DSDT and
>>> elsewhere which lead to non-functional keyboard/mouse.
>>
>> Are we certain about that? Any pointers to reports?
>>
>>>
>>>> It would seem
>>>> like a better idea to fix this rather than adding yet another DMI
>>>> list (especially since there likely are, or will be, machines
>>>> without i8042 other than Macs).
>>>>
>>>
>>> If they are not Macs that mean they are tested with windows and thus
>>> expect probes in i8042 port region so no harm done. In a few years if
>>> everyone uses USB only we could add a year threshold to trust ACPI/PNP
>>> data.
>>
>> Macs will be tested with Windows too, so obviously it manages to avoid
>> this problem somehow, and I very much doubt it has an Apple-specific
>> check..
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
> I've an iMac, and a macbook over here,
> if you guys need me to test out a patch for this let me know.

Can you (and probably Bastien or whoever had the problematic machine)
check the output of:

cat /sys/bus/pnp/devices/*/id

and see if any of these are present?

PNP0303
PNP030b
FJC6000
FJC6001
PNP0f03
PNP0f0b
PNP0f0e
PNP0f12
PNP0f13
PNP0f19
PNP0f1c
SYN0801
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/