mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bastien Nocera <hadess@hadess.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Robert Hancock <hancockrwd@gmail.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	pjones@redhat.com, vojtech@suse.cz
Subject: Re: [PATCH] Disable i8042 checks on Intel Apple Macs
Date: Fri, 22 Jan 2010 18:15:46 +0000	[thread overview]
Message-ID: <1264184146.2556.649.camel@localhost.localdomain> (raw)
In-Reply-To: <4B59E47D.8010702@zytor.com>

On Fri, 2010-01-22 at 09:46 -0800, H. Peter Anvin wrote:
> On 01/21/2010 04:26 PM, Robert Hancock wrote:
> >>
> >> 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.
> > 
> 
> You think it's reasonable to have the keyboard not work because
> someone's KVM switch was in the wrong position when the system booted?
> Sorry, that's not how the world works.  It's sad that someone had the
> bright idea that things should work that way, but that is definitely a
> regression I wouldn't want to deal with.
> 
> The only thing that I could think of as a reasonable limit would be to
> not probe these ports if we are booted from EFI/UEFI.  That would cover
> the ia64 case, too.  However, I'm hardly confident that we wouldn't have
> the same class of problems even there.

Then I would guess that you think the manner in which I disabled the
i8042 checks in the original patch is viable/mergeable?

/Bastien, not sure who would have the last word


  reply	other threads:[~2010-01-22 18:15 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-20 18:23 Bastien Nocera
2010-01-20 19:14 ` Justin P. Mattock
2010-01-20 19:37   ` Bastien Nocera
2010-01-20 19:54     ` Justin P. Mattock
2010-01-21  0:41 ` Robert Hancock
2010-01-21  1:31   ` Bastien Nocera
2010-01-21  2:19     ` Robert Hancock
2010-01-21 18:55   ` Dmitry Torokhov
2010-01-21 21:39     ` Robert Hancock
2010-01-21 21:42       ` Bastien Nocera
2010-01-21 21:49       ` Justin P. Mattock
2010-01-22  0:29         ` Robert Hancock
2010-01-22  1:20           ` Justin P. Mattock
2010-01-22  2:09             ` Bastien Nocera
2010-01-22  2:30               ` Robert Hancock
2010-01-22  2:53                 ` Bastien Nocera
2010-01-22  2:31               ` Justin P. Mattock
2010-01-21 22:17       ` Dmitry Torokhov
2010-01-22  0:26         ` Robert Hancock
2010-01-22 17:46           ` H. Peter Anvin
2010-01-22 18:15             ` Bastien Nocera [this message]
2010-01-22 22:33             ` Robert Hancock
2010-01-22 22:49               ` H. Peter Anvin
2010-01-25 16:34         ` Vojtech Pavlik
2010-01-25 21:32           ` H. Peter Anvin
2010-01-25 22:15             ` Dmitry Torokhov
2010-01-25 22:18               ` H. Peter Anvin
2010-01-25 22:30                 ` Dmitry Torokhov
2010-01-25 23:05                   ` H. Peter Anvin
2010-01-25 23:28                     ` Dmitry Torokhov
2010-01-25 23:31                       ` H. Peter Anvin
2010-05-04 17:06               ` Bastien Nocera
2010-05-04 17:23                 ` Dmitry Torokhov
2010-05-04 17:37                   ` Bastien Nocera
2010-05-04 17:36 Bastien Nocera
2010-05-04 17:55 ` Pekka Enberg
2010-05-04 18:02 ` Dmitry Torokhov
2010-05-05  9:18   ` Bastien Nocera
2010-05-05 21:27 ` Kyle McMartin
2010-05-12  0:11 Bastien Nocera
2010-05-12 10:51 ` Felipe Contreras
2010-05-12 11:00   ` Felipe Contreras
2010-05-12 17:51   ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1264184146.2556.649.camel@localhost.localdomain \
    --to=hadess@hadess.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hancockrwd@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=vojtech@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome