Message ID | s5hk2bn908b.wl-tiwai@suse.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Mon, 28 Nov 2016 14:56:36 +0100, Takashi Iwai wrote: > > Hi Dmitry, > > I've been testing a small machine with Intel Cherry Trail chipset, and > noticed that the kernel spews errors always like: > > i8042: PNP: No PS/2 controller found. Probing ports directly. > i8042: Can't read CTR while initializing i8042 > i8042: probe of i8042 failed with error -5 > > Especially the second one ("Can't read CTR...") is annoying since it's > in KERN_ERR level and thus appears even booted with quiet boot > option. Actually this is the only error message appearing at boot, so > I'd love to get rid of it. > > What is the preferred way to reduce this? For example, is a patch > like below OK to simply change the log level and the error code? Any suggestion? Adding Jiri to Cc, as he had a similar issue in the past. thanks, Takashi > > > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai <tiwai@suse.de> > Subject: [PATCH] i8042: Reduce the log level of i8042 CTR read error > > The error message "Can't read CTR while initializing i8042" appears on > Cherry Trail-based devices at each boot time: > > i8042: PNP: No PS/2 controller found. Probing ports directly. > i8042: Can't read CTR while initializing i8042 > i8042: probe of i8042 failed with error -5 > > This is annoying, since it's the only error message with KERN_ERR > level appearing during the boot. > > This patch changes the kernel log level to KERN_INFO for that message, > and replaces the error code to -ENODEV so that this probe failure > won't be complained like the above. > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/input/serio/i8042.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c > index b4e1ac5c9ea8..2c2683e357e9 100644 > --- a/drivers/input/serio/i8042.c > +++ b/drivers/input/serio/i8042.c > @@ -980,8 +980,8 @@ static int i8042_controller_init(void) > udelay(50); > > if (i8042_command(&ctr[n++ % 2], I8042_CMD_CTL_RCTR)) { > - pr_err("Can't read CTR while initializing i8042\n"); > - return -EIO; > + pr_info("Can't read CTR while initializing i8042\n"); > + return -ENODEV; > } > > } while (n < 2 || ctr[0] != ctr[1]); > -- > 2.10.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Takashi, On Mon, Nov 28, 2016 at 02:56:36PM +0100, Takashi Iwai wrote: > Hi Dmitry, > > I've been testing a small machine with Intel Cherry Trail chipset, and > noticed that the kernel spews errors always like: > > i8042: PNP: No PS/2 controller found. Probing ports directly. > i8042: Can't read CTR while initializing i8042 > i8042: probe of i8042 failed with error -5 > > Especially the second one ("Can't read CTR...") is annoying since it's > in KERN_ERR level and thus appears even booted with quiet boot > option. Actually this is the only error message appearing at boot, so > I'd love to get rid of it. > > What is the preferred way to reduce this? For example, is a patch > like below OK to simply change the log level and the error code? No, because if controller is actually present this is a hard failure and we should be reporting it, not suppressing it. The issue is that we did not believe PNP data and in this case we should have. Unfortunately in old days there was a lot of crap in PNP/ACPI tables, but it could be better now. We can try, in addition to PNP matching, checking 8042 flag in "Fixed ACPI Description Table Boot Architecture Flags" in FADT and if it also shows there is no 8042 then bail. Thanks. > > > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai <tiwai@suse.de> > Subject: [PATCH] i8042: Reduce the log level of i8042 CTR read error > > The error message "Can't read CTR while initializing i8042" appears on > Cherry Trail-based devices at each boot time: > > i8042: PNP: No PS/2 controller found. Probing ports directly. > i8042: Can't read CTR while initializing i8042 > i8042: probe of i8042 failed with error -5 > > This is annoying, since it's the only error message with KERN_ERR > level appearing during the boot. > > This patch changes the kernel log level to KERN_INFO for that message, > and replaces the error code to -ENODEV so that this probe failure > won't be complained like the above. > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/input/serio/i8042.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c > index b4e1ac5c9ea8..2c2683e357e9 100644 > --- a/drivers/input/serio/i8042.c > +++ b/drivers/input/serio/i8042.c > @@ -980,8 +980,8 @@ static int i8042_controller_init(void) > udelay(50); > > if (i8042_command(&ctr[n++ % 2], I8042_CMD_CTL_RCTR)) { > - pr_err("Can't read CTR while initializing i8042\n"); > - return -EIO; > + pr_info("Can't read CTR while initializing i8042\n"); > + return -ENODEV; > } > > } while (n < 2 || ctr[0] != ctr[1]); > -- > 2.10.2 >
On Thu, 01 Dec 2016 03:29:23 +0100, Dmitry Torokhov wrote: > > Hi Takashi, > > On Mon, Nov 28, 2016 at 02:56:36PM +0100, Takashi Iwai wrote: > > Hi Dmitry, > > > > I've been testing a small machine with Intel Cherry Trail chipset, and > > noticed that the kernel spews errors always like: > > > > i8042: PNP: No PS/2 controller found. Probing ports directly. > > i8042: Can't read CTR while initializing i8042 > > i8042: probe of i8042 failed with error -5 > > > > Especially the second one ("Can't read CTR...") is annoying since it's > > in KERN_ERR level and thus appears even booted with quiet boot > > option. Actually this is the only error message appearing at boot, so > > I'd love to get rid of it. > > > > What is the preferred way to reduce this? For example, is a patch > > like below OK to simply change the log level and the error code? > > No, because if controller is actually present this is a hard failure and > we should be reporting it, not suppressing it. > > The issue is that we did not believe PNP data and in this case we should > have. Unfortunately in old days there was a lot of crap in PNP/ACPI > tables, but it could be better now. We can try, in addition to PNP > matching, checking 8042 flag in "Fixed ACPI Description Table Boot > Architecture Flags" in FADT and if it also shows there is no 8042 then > bail. That sounds promising. Indeed FACL.dsl shows like: [000h 0000 4] Signature : "FACP" [Fixed ACPI Description Table (FADT)] [004h 0004 4] Table Length : 0000010C .... Legacy Devices Supported (V2) : 0 8042 Present on ports 60/64 (V2) : 0 If a test patch gets ready, let me know, I'll give it a try. Thanks! Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c index b4e1ac5c9ea8..2c2683e357e9 100644 --- a/drivers/input/serio/i8042.c +++ b/drivers/input/serio/i8042.c @@ -980,8 +980,8 @@ static int i8042_controller_init(void) udelay(50); if (i8042_command(&ctr[n++ % 2], I8042_CMD_CTL_RCTR)) { - pr_err("Can't read CTR while initializing i8042\n"); - return -EIO; + pr_info("Can't read CTR while initializing i8042\n"); + return -ENODEV; } } while (n < 2 || ctr[0] != ctr[1]);