All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>, linux-input@vger.kernel.org
Subject: Re: Delaying i8042 probe?
Date: Tue, 05 Oct 2021 17:43:23 +0200	[thread overview]
Message-ID: <s5hpmsjcw9w.wl-tiwai@suse.de> (raw)
In-Reply-To: <s5hh7ekc1tw.wl-tiwai@suse.de>

On Thu, 16 Sep 2021 11:22:03 +0200,
Takashi Iwai wrote:
> 
> On Sun, 12 Sep 2021 00:54:55 +0200,
> Dmitry Torokhov wrote:
> > 
> > Hi Fabio,
> > 
> > On Sat, Sep 11, 2021 at 03:50:25PM -0300, Fabio Estevam wrote:
> > > On Sat, Sep 11, 2021 at 3:43 PM Fabio Estevam <festevam@gmail.com> wrote:
> > > >
> > > > On Sat, Sep 11, 2021 at 4:32 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > >
> > > > > OK, I'll update and let the reporter testing it.
> > > >
> > > > Sorry, platform_device_alloc() and platform_device_add() were missing
> > > > in the earlier patch.
> > > >
> > > > New patch atached.
> > > >
> > > > Dmitry, does this look correct?
> > > 
> > > Please consider this one instead.
> > 
> > This is unfortunately is a band-aid. I wonder what other driver pokes
> > the embedded controller on these devices for it to start responding to
> > 8042 queries...
> > 
> > Does the laptop have the latest BIOS? I wonder what ACPI tables look
> > like.
> 
> ACPI dump is included in hwinfo output,
>   https://bugzilla.suse.com/show_bug.cgi?id=1190256#c1
> 
> If other format is required, let me know.  I thought this could be a
> typical pinctrl thing, alas it doesn't look so.  The pinctrl-amd is
> also built-in, and it's initialized before the input stuff...
> 
> And about BIOS: I don't think we can expect every user updates BIOS.
> This report is not alone; as I checked through net, there have been a
> few other reports for other distros like Arch.  On Arch, they "fixed"
> the problem by reverting the config from built-in to modules (the bug
> surfaced after their kconfig changes).
> 
> That said, even if it's a band-aid, we need some fix.  Can the
> deferred probe be applied in some restricted manner, e.g. only for the
> known buggy devices (and/or module option) and cap the max repeats?

Dmitry, what is your take for fixing this bug?  

I find Fabio's deferred probe patch reasonable.  Maybe we may restrict
the application of the deferred probe only for known working devices
and an option, something like a patch below, just to be safer.
(There are devices exposing PnP for i8042 although there isn't really,
IIRC.)


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] Input: i8042 - Perform deferred probe only with DMI list and
 option

Add an i8042.probe_defer option to enable the deferred probing
feature, otherwise it'll be disabled and done in a single shot like
before.  For the known devices that need the deferred probe, we
provide a DMI-based allow-list.  As of this patch, ASUS ZenBook
UX425UA is added there.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 Documentation/admin-guide/kernel-parameters.txt |  2 ++
 drivers/input/serio/i8042-x86ia64io.h           | 14 ++++++++++++++
 drivers/input/serio/i8042.c                     |  6 +++++-
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 91ba391f9b32..6e6622d8f4a0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1690,6 +1690,8 @@
 			architectures force reset to be always executed
 	i8042.unlock	[HW] Unlock (ignore) the keylock
 	i8042.kbdreset	[HW] Reset device connected to KBD port
+	i8042.probe_defer
+			[HW] Allow deferred probing upon i8042 probe errors
 
 	i810=		[HW,DRM]
 
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index a5a003553646..41335a1d7001 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -981,6 +981,17 @@ static const struct dmi_system_id __initconst i8042_dmi_kbdreset_table[] = {
 	{ }
 };
 
+static const struct dmi_system_id i8042_dmi_probe_defer_table[] __initconst = {
+	{
+		/* ASUS ZenBook UX425UA */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "ZenBook UX425UA"),
+		},
+	},
+	{ }
+};
+
 #endif /* CONFIG_X86 */
 
 #ifdef CONFIG_PNP
@@ -1301,6 +1312,9 @@ static int __init i8042_platform_init(void)
 	if (dmi_check_system(i8042_dmi_kbdreset_table))
 		i8042_kbdreset = true;
 
+	if (dmi_check_system(i8042_dmi_probe_defer_table))
+		i8042_probe_defer = true;
+
 	/*
 	 * A20 was already enabled during early kernel init. But some buggy
 	 * BIOSes (in MSI Laptops) require A20 to be enabled using 8042 to
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index a72a8c538164..ea0c52ca95c4 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -45,6 +45,10 @@ static bool i8042_unlock;
 module_param_named(unlock, i8042_unlock, bool, 0);
 MODULE_PARM_DESC(unlock, "Ignore keyboard lock.");
 
+static bool i8042_probe_defer;
+module_param_named(probe_defer, i8042_probe_defer, bool, 0);
+MODULE_PARM_DESC(unlock, "Allow deferred probing.");
+
 enum i8042_controller_reset_mode {
 	I8042_RESET_NEVER,
 	I8042_RESET_ALWAYS,
@@ -1005,7 +1009,7 @@ static int i8042_controller_init(void)
 
 		if (i8042_command(&ctr[n++ % 2], I8042_CMD_CTL_RCTR)) {
 			pr_err("Can't read CTR while initializing i8042\n");
-			return -EPROBE_DEFER;
+			return i8042_probe_defer ? -EPROBE_DEFER : -EIO;
 		}
 
 	} while (n < 2 || ctr[0] != ctr[1]);
-- 
2.31.1


  reply	other threads:[~2021-10-05 15:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10 10:49 Delaying i8042 probe? Takashi Iwai
2021-09-10 11:07 ` Fabio Estevam
2021-09-10 12:07   ` Takashi Iwai
2021-09-11  1:36     ` Fabio Estevam
2021-09-11  7:32       ` Takashi Iwai
2021-09-11 18:43         ` Fabio Estevam
2021-09-11 18:50           ` Fabio Estevam
2021-09-11 22:54             ` Dmitry Torokhov
2021-09-16  9:22               ` Takashi Iwai
2021-10-05 15:43                 ` Takashi Iwai [this message]
2021-10-19  5:41                   ` Takashi Iwai
2021-09-16  9:16             ` Takashi Iwai
2021-09-17 11:36               ` Fabio Estevam

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=s5hpmsjcw9w.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=festevam@gmail.com \
    --cc=linux-input@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.