Input updates for 2.6.34-rc6
in [Kernel]
|
Prev: HWPOISON for hugepage (v5)
Next: gta02: Use pcf50633 backlight driver instead of platform backlight driver.
From: Dmitry Torokhov on 13 May 2010 12:10 On Thu, May 13, 2010 at 07:35:02AM -0700, Linus Torvalds wrote: > > > 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. I will freely admit that none of the fixes would qualify as strictly regression fixes. The cacheline issue on ad7877 was there in the very first version of the driver being committed, iforce got 1 new product ID and a fix to another product ID which was there for ages, psmouse changes tries to work around issue on a laptop that is not out yet as far as I know... All of these however are very small, with low risk of disturbing anyone, and making users life better. That is why I thought that rather than having them wait for another 3 months we sould get the fixes out earlier. > 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. > Sometimes we do need to resort to DMI quirks because we do not have anything else to go on and i8042 is littered with such cases. Half of the boxes claim to support active multiplexing but don't. HOwever when it works it is a useful thing (on laptop both touchpad and external mice can work independently with their full protocols instead of degrading both to Intellimouse, like Dells do). Some BIOSes hang if you use AUX LOOP. And so on. Apple does proper thing in BIOS and omits keyboard and mouse PNP devices, but because of other players we do not really trust PNP BIOS and resort to banding on ports directly - there are cases when box has mouse and/or keyboard but they are not present in BIOS. Damed if you do, damned if you don't... > 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 -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 13 May 2010 12:20 On Thu, 13 May 2010, Dmitry Torokhov wrote: > > From what I remember (it was a few weeks old thread) we were hanging > when trying to read from the controller in i8042_flush(). Normally, if > controller isn't there we'd get a stream of 0xff which will never > "clear" and so after 32 reads we give up and abort controller > initialization. But on Bastien's box it just sits there. Is there a web interface to some archive for linux-input (or was this thread on lkml)? Anyway, the fact that apparently pressing the power button makes it come alive again implies that it's likely SCI/SMI-related. Which is not entirely unexpected if there is some crazy SMM thing going on. But presumably whatever buggy Apple code is _supposed_ to work for Windows, so I wonder what bug that quite simple status/data register read could possibly trigger. Is it the status read or the data read that causes problems, and is it the first one or after doing a few? A couple of printk's in that i8042_flush() routine should tell us. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Randy Dunlap on 13 May 2010 12:40 On Thu, 13 May 2010 09:16:31 -0700 (PDT) Linus Torvalds wrote: > > > On Thu, 13 May 2010, Dmitry Torokhov wrote: > > > > From what I remember (it was a few weeks old thread) we were hanging > > when trying to read from the controller in i8042_flush(). Normally, if > > controller isn't there we'd get a stream of 0xff which will never > > "clear" and so after 32 reads we give up and abort controller > > initialization. But on Bastien's box it just sits there. > > Is there a web interface to some archive for linux-input (or was this > thread on lkml)? From Jan. 20, on lkml. See http://lkml.org/lkml/2010/1/20/254 > Anyway, the fact that apparently pressing the power button makes it come > alive again implies that it's likely SCI/SMI-related. Which is not > entirely unexpected if there is some crazy SMM thing going on. But > presumably whatever buggy Apple code is _supposed_ to work for Windows, so > I wonder what bug that quite simple status/data register read could > possibly trigger. > > Is it the status read or the data read that causes problems, and is it the > first one or after doing a few? A couple of printk's in that i8042_flush() > routine should tell us. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 13 May 2010 13:00 On Thu, 13 May 2010, Dmitry Torokhov wrote: > > Apple does proper thing in BIOS and omits keyboard and mouse PNP > devices, but because of other players we do not really trust PNP BIOS > and resort to banding on ports directly - there are cases when box has > mouse and/or keyboard but they are not present in BIOS. Damed if you do, > damned if you don't... Umm. No. PnP information _commonly_ doesn't inclure PS/2 ports, even when they exist. Lack of PnP information about the keyboard port means absolutely nothing, and anybody who tells you otherwise is totally and utterly wrong. So don't confuse this with PnP issues. That's a total red herring, and Apple is _not_at_all_ "doing the proper thing in the BIOS". Quite the reverse. Apple is very clearly doing something horribly _wrong_ in their BIOS. Don't give them kudos for being incompetent morons. Just google for "Probing ports directly" "i8042 KBD port" and you'll get a lot of hits. That's not because those machines have wrong PnP tables - it's because fundamentally PNP is a joke, and on PC's what is much more important is "standard IO ports". For example, in that thread, Bastien is quoted: > 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. and all that tells me is that Bastien doesn't know what he is doing. It is _not_ "randomly bang" - it's called standard PC hardware. And it's not "misguided" - it's very much correct and required, exactly because PnP itself is the misguided aborted fetus of a braindamaged mind. We do not trust BIOS tables, because BIOS writers are invariably totally incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS writers. QED. And in fact the Apple problem is an _example_ of this BIOS writer incompetence, not some shining example of them doing something right. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 13 May 2010 13:10
On Thu, 13 May 2010, Linus Torvalds wrote: > > PnP information _commonly_ doesn't inclure PS/2 ports, even when they > exist. Lack of PnP information about the keyboard port means absolutely > nothing, and anybody who tells you otherwise is totally and utterly wrong. > > So don't confuse this with PnP issues. That's a total red herring, and > Apple is _not_at_all_ "doing the proper thing in the BIOS". Btw, was this an EFI boot? I could easily see bootcamp working (it's been tested with Windows, after all), but not EFI (I've heard rumors of Windows booting from EFI, but I don't know if those are actually correct). And I'd be a _lot_ more open to saying "if you booted from EFI, then we're going to ignore any legacy devices that aren't in PnP tables". In fact, we effectively do that today by having different code-paths for ia64 (which was EFI) and x86 (which is obviously traditionally not EFI). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |