mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-input@vger.kernel.org, Bastien Nocera <hadess@hadess.net>
Subject: Re: [git pull] Input updates for 2.6.34-rc6
Date: Thu, 13 May 2010 07:35:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1005130724280.3711@i5.linux-foundation.org> (raw)
In-Reply-To: <20100513075728.GF30110@core.coreip.homeip.net>



On Thu, 13 May 2010, Dmitry Torokhov wrote:
> 
> Bastien Nocera (1):
>       Input: i8042 - do not try to probe ports on Intel Apple Macs

I pulled, but I skipped the last commit, because I think this one is 
fundamentally _wrong_.

It is _not_ maintainable to create random tables of exceptions ("DMI 
tables"), and it's actively _wrong_ to do for something like this where we 
not only have historically worked perfectly well, and this apparently 
tries to hide some other bug (the commit says "could potentially lock 
up/hang/wait for timeout for long periods of time").

We should fix the problems instead of hiding them for specific machines. 
Does anybody really think that Apple machines are the only ones with no 
legacy keyboard? Hello? Does anybody seriously think that it's ok to add 
entries to DMI tables for random new machines coming out?

So I think that commit was (a) totally inappropriate to send at this point 
in the late -rc series _anyway_ (it sure as hell isn't a refression fix), 
and that makes me wonder about the other ones. But (b) I don't think I 
want to ever see anything like that during a merge window either, because 
it's quite seriously the wrong thing to do.

What are the _actual_ problems on legacy-free machines? And keep in mind 
that I ask that exactly because I actually _have_ two Apple Mac Mini's in 
my household, and have never seen any problems with keyboard/mouse 
handling. 

So if somebody saw "could potentially lock up/hang/wait" issues, then 
dangit, say what those issues are, AND LET'S FIX THEM! And not like this, 
trying to hide them for some particular machines, rather than fixing the 
actual underlying detection bug.

			Linus

  reply	other threads:[~2010-05-13 14:37 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-13  7:57 Dmitry Torokhov
2010-05-13 14:35 ` Linus Torvalds [this message]
2010-05-13 14:47   ` Bastien Nocera
2010-05-13 15:04     ` Linus Torvalds
2010-05-13 15:19       ` Linus Torvalds
2010-05-13 15:50       ` Dmitry Torokhov
2010-05-13 16:16         ` Linus Torvalds
2010-05-13 16:38           ` Randy Dunlap
2010-05-13 20:15         ` Matthew Garrett
2010-05-13 16:01   ` Dmitry Torokhov
2010-05-13 16:54     ` Linus Torvalds
2010-05-13 16:58       ` Linus Torvalds
2010-05-13 17:16       ` Dmitry Torokhov
2010-05-13 17:30         ` Linus Torvalds
2010-05-13 18:10           ` Dmitry Torokhov
2010-05-13 19:55             ` Linus Torvalds
2010-05-14  7:56               ` Eric W. Biederman
2010-05-14 14:54                 ` Linus Torvalds
2010-05-14 15:38                   ` Matthew Garrett
2010-05-14 15:42                     ` Linus Torvalds
2010-05-14 15:49                       ` Matthew Garrett
2010-05-20  4:53                         ` Len Brown
     [not found]             ` <alpine.LFD.2.00.1005131232350.3711@i5.linux-foundation.org>
2010-05-13 21:05               ` Dmitry Torokhov
2010-05-13 21:21                 ` Linus Torvalds
2010-05-13 23:39                 ` Matthew Garrett
2010-05-20  4:56                 ` Len Brown
2010-05-20  7:08                   ` Dmitry Torokhov
2010-05-27  6:22       ` Robert Hancock
2010-05-27  6:43         ` Dmitry Torokhov
2010-05-27 17:06         ` Linus Torvalds
2010-05-27 23:03           ` Robert Hancock
2010-05-28  0:46             ` Linus Torvalds
2010-05-28  1:03               ` Dmitry Torokhov
2010-05-28  4:05                 ` Robert Hancock
2010-05-28  5:10                   ` Dmitry Torokhov
2010-05-14 14:55   ` Matthew Garrett
2010-05-14 15:16     ` Linus Torvalds
2010-05-14 16:28       ` Dmitry Torokhov
2010-05-14 18:47       ` david
2010-05-14 18:49         ` Matthew Garrett
2010-05-14 18:55           ` david
2010-05-14 18:59             ` Matthew Garrett
2010-05-14 19:05             ` david
2010-05-28  2:38       ` Mike Frysinger
2010-08-04  6:20       ` Dmitry Torokhov
2010-08-04  6:29         ` Dmitry Torokhov
2010-05-14 16:29     ` Dmitry Torokhov
2010-05-14 16:35       ` Matthew Garrett
  -- strict thread matches above, loose matches on Subject: below --
2010-05-05  6:41 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=alpine.LFD.2.00.1005130724280.3711@i5.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hadess@hadess.net \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®