Skip to contentSkip to conversation

: Add command-line option to i8042 to completely disable it

PATCH In review Chris Lalancette 3 participants 4 messages Jul 23, 2007 – Jul 25, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 : Add command-line option to i8042 to completely disable it

(I tried to send this patch to linux-input@, but it seems to be currently having some problems, so I'm going directly to LKML).

Certain (broken) pieces of South Bridge hardware will respond to i8042_read_status() on boot with 0x0, despite there not being a real i8042 controller hooked up in the south bridge. This can cause the detection for the i8042 to return a "phantom" device, which hangs up later initialization. Note that using "i8042.nokbd" and/or "i8042.noaux" do not help with this, since this shows up during i8042_controller_check() (before either of those options are checked). This patch adds a command-line option "i8042.disable", which just completely disables any checking for the i8042 controller.

drivers/input/serio/i8042.c +9 -0
index 3888dc3..a13039c 100644
@@ -27,6 +27,10 @@ MODULE_AUTHOR("Vojtech Pavlik <[email protected]>");
 MODULE_DESCRIPTION("i8042 keyboard and mouse controller driver");
 MODULE_LICENSE("GPL");
 
+static unsigned int i8042_disable;
+module_param_named(disable, i8042_disable, bool, 0);
+MODULE_PARM_DESC(disable, "Do not probe i8042 at all.");
+
 static unsigned int i8042_nokbd;
 module_param_named(nokbd, i8042_nokbd, bool, 0);
 MODULE_PARM_DESC(nokbd, "Do not probe or use KBD port.");
@@ -1194,6 +1198,11 @@ static int __init i8042_init(void)
 {
 	int err;
 
+	if (i8042_disable) {
+		printk(KERN_ERR "i8042.c: Controller disabled by kernel command-line\n");
+		return -ENODEV;
+	}
+
 	dbg_init();
 
 	err = i8042_platform_init();
#1 lore raw
Quoted 11 lines · On Mon, 23 Jul 2007 13:05:22 -0400 Chris Lalancette <[email protected]> wrote:

(I tried to send this patch to linux-input@, but it seems to be currently having some problems, so I'm going directly to LKML).

Certain (broken) pieces of South Bridge hardware will respond to i8042_read_status() on boot with 0x0, despite there not being a real i8042 controller hooked up in the south bridge. This can cause the detection for the i8042 to return a "phantom" device, which hangs up later initialization. Note that using "i8042.nokbd" and/or "i8042.noaux" do not help with this, since this shows up during i8042_controller_check() (before either of those options are checked). This patch adds a command-line option "i8042.disable", which just completely disables any checking for the i8042 controller.

That's an unfortunate fix. Is there really no way in which we can auto-detect such a situation without requiring a manual setting?

#2 lore raw
Quoted 14 lines · Andrew Morton
Quoted 11 lines · On Mon, 23 Jul 2007 13:05:22 -0400 Chris Lalancette <[email protected]> wrote:

(I tried to send this patch to linux-input@, but it seems to be currently having some problems, so I'm going directly to LKML).

Certain (broken) pieces of South Bridge hardware will respond to i8042_read_status() on boot with 0x0, despite there not being a real i8042 controller hooked up in the south bridge. This can cause the detection for the i8042 to return a "phantom" device, which hangs up later initialization. Note that using "i8042.nokbd" and/or "i8042.noaux" do not help with this, since this shows up during i8042_controller_check() (before either of those options are checked). This patch adds a command-line option "i8042.disable", which just completely disables any checking for the i8042 controller.

Quoted 3 lines

That's an unfortunate fix. Is there really no way in which we can auto-detect such a situation without requiring a manual setting?

The fact that the current detection hangs suggests that the scenario is possible to detect.

Signature · 2 lines
Vojtech Pavlik
Director SuSE Labs
#3 lore raw
Quoted 9 lines · Vojtech Pavlik
Quoted 4 lines

That's an unfortunate fix. Is there really no way in which we can auto-detect such a situation without requiring a manual setting?

The fact that the current detection hangs suggests that the scenario is possible to detect.

Hm, OK. I'll go back and look at i8042_flush() to see if I can detect this erroneous situation automatically and fail the i8042_controller_init() if I see it.

Chris Lalancette