Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752476Ab0AVAaA (ORCPT ); Thu, 21 Jan 2010 19:30:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751395Ab0AVA37 (ORCPT ); Thu, 21 Jan 2010 19:29:59 -0500 Received: from mail-iw0-f196.google.com ([209.85.223.196]:60487 "EHLO mail-iw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750732Ab0AVA36 convert rfc822-to-8bit (ORCPT ); Thu, 21 Jan 2010 19:29:58 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i9G5gk6LsaHrKEYQ/SJ/typRvbhNz4IarARo5e9WTj3eN/am35+WgTg7g14LF6GE2E X/AW4oW/Er48CGZ/rqh6pAEjxhDERPjIO/q9z2Qt8mK7rYmdgbEv4Cnipe2rxcESwPG1 kYHE03dRGdINz7PT4UR5F7+/F0MTNG1SZ+fgc= MIME-Version: 1.0 In-Reply-To: <4B58CBEE.5020301@gmail.com> References: <1264011793.1735.3683.camel@localhost.localdomain> <4B57A2D4.9030204@gmail.com> <20100121185544.GB11996@core.coreip.homeip.net> <51f3faa71001211339t4652700ct34659c37479cd67e@mail.gmail.com> <4B58CBEE.5020301@gmail.com> Date: Thu, 21 Jan 2010 18:29:56 -0600 Message-ID: <51f3faa71001211629n1b556649t32c184e49dc32dfb@mail.gmail.com> Subject: Re: [PATCH] Disable i8042 checks on Intel Apple Macs From: Robert Hancock To: "Justin P. Mattock" Cc: Dmitry Torokhov , Bastien Nocera , linux-kernel , pjones@redhat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3049 Lines: 91 On Thu, Jan 21, 2010 at 3:49 PM, Justin P. Mattock wrote: > On 01/21/10 13:39, Robert Hancock wrote: >> >> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov >> ?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 >>>> >>>> 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@vger.kernel.org >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/