On Thu, Jan 21, 2010 at 4:17 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
quoted text
> On Thu, Jan 21, 2010 at 03:39:25PM -0600, Robert Hancock wrote:
>> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> 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@hadess.net>
>> >>
>> >> 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?
>>
>
> This is from the changelog when this was introduced:
>
> -------------------------------------------------------------------------
> 2005/02/25 21:21:03+01:00 vojtech
> input: After testing on real world hardware, it's obvious we can't trust
>       ACPIPnP nor PnPBIOS to properly report the existence of a keyboard
>       and mouse port in all cases. Some BIOSes hide the ports if no mouse
>       or keyboard is connected, causing trouble with eg. KVM switches.

If it's just that case (which isn't certain given Vojtech's report),
then I think it's reasonable to ignore that by default. If the BIOS
decided to hide the controller then our default behavior should be to
believe it, with the ability to override that if necessary, not the
other way around.

quoted text
>
>       The i8042 driver now does read-only probing first, which should
>       not cause any problems even if an i8042 controller really is not
>       present.
>
>       However, on IA64 we still need to trust ACPI, since legacy-free
>       hardware is common there and invalid port accesses cause exceptions.
>
>  Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>
>
>>> Input: Add ACPI-based i8042 keyboard and aux controller enumeration;
>> > can be disabled by passing i8042.noacpi as a boot parameter.
>>
>> On a whim I decided to turn on ACPI, only to discover that my keyboard
>> no longer worked. Passing i8042.noacpi=1 makes it work again.
>> Attached please find boot messages with and without the boot
>> parameter. Inlined below is a diff of the two.
>
> --------------------------------------------------------------------------
>
> I'm adding Vojtech in case he manages to recall what other failures he
> has seen.
>
>> >
>> >> 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..
>
> Why not?

Some of the supported Windows versions were likely released before any
Intel-based Macs, which would make such a check impossible.

I think we're far too quick to add DMI lists for things in the kernel.
If there's a way we can just do the right thing, we should be.
--
unsubscribe notice
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/