From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47AE5C433F5 for ; Tue, 5 Oct 2021 15:43:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2DA3C61159 for ; Tue, 5 Oct 2021 15:43:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235588AbhJEPpP (ORCPT ); Tue, 5 Oct 2021 11:45:15 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:44106 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231513AbhJEPpP (ORCPT ); Tue, 5 Oct 2021 11:45:15 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D03DD2003B; Tue, 5 Oct 2021 15:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633448603; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LYcyNSBFYAWeK30AFwM9CLCFhu52fa/XU+fDppW8tGE=; b=SLiDv4qx4zKnX8i/BNhuwzMbxhqpo3wbXiHN9MpiMWug6bacH+9woTCo62eP7uoVaPf2ce RTc9uuoTCFXfAdvI+aS1BluJgjbmsjbBoJ3OWIIKuYnGrMYK6BJMYUfUlGgjm2/uDunb+i Yvmf+f1orh4dqpE8GDcbHqkm/53aq0M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633448603; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LYcyNSBFYAWeK30AFwM9CLCFhu52fa/XU+fDppW8tGE=; b=ir71L5cqaAtN+XPwdUHjWy79ex3ZmFwf9o9WpS3G9jfAtdQ/HRLc2gT+EmDPJqXOBSpti5 9VpmKJlsy1JXWZAQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id C9E3CA3B9B; Tue, 5 Oct 2021 15:43:23 +0000 (UTC) Date: Tue, 05 Oct 2021 17:43:23 +0200 Message-ID: From: Takashi Iwai To: Dmitry Torokhov Cc: Fabio Estevam , linux-input@vger.kernel.org Subject: Re: Delaying i8042 probe? In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org 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 wrote: > > > > > > > > On Sat, Sep 11, 2021 at 4:32 AM Takashi Iwai 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 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 --- 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