Re: i8042 error at booting an Intel Cherry Trail-based device

On Tue, 06 Dec 2016 07:07:54 +0100,
Dmitry Torokhov wrote:

On December 5, 2016 4:56:05 PM PST, Marcos Paulo de Souza [off-list ref] wrote:

quoted

Hi Takashi,

On Fri, Dec 02, 2016 at 11:55:07AM +0100, Takashi Iwai wrote:

quoted

On Thu, 01 Dec 2016 08:19:46 +0100,
Takashi Iwai wrote:

quoted

On Thu, 01 Dec 2016 03:29:23 +0100,
Dmitry Torokhov wrote:

quoted

Hi Takashi,

On Mon, Nov 28, 2016 at 02:56:36PM +0100, Takashi Iwai wrote:

quoted

Hi Dmitry,

I've been testing a small machine with Intel Cherry Trail

chipset, and

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

in KERN_ERR level and thus appears even booted with quiet boot
option.  Actually this is the only error message appearing at

boot, so

quoted

quoted

quoted

quoted

I'd love to get rid of it.

What is the preferred way to reduce this?  For example, is a

patch

quoted

quoted

quoted

quoted

like below OK to simply change the log level and the error

code?

quoted

quoted

quoted

No, because if controller is actually present this is a hard

failure and

quoted

quoted

quoted

we should be reporting it, not suppressing it.

The issue is that we did not believe PNP data and in this case we

should

quoted

quoted

quoted

have. Unfortunately in old days there was a lot of crap in

PNP/ACPI

quoted

quoted

quoted

tables, but it could be better now. We can try, in addition to

PNP

quoted

quoted

quoted

matching, checking 8042 flag in "Fixed ACPI Description Table

Boot

quoted

quoted

quoted

Architecture Flags" in FADT and if it also shows there is no 8042

then

quoted

quoted

quoted

bail.

That sounds promising.  Indeed FACL.dsl shows like:

[000h 0000   4]                    Signature : "FACP"    [Fixed

ACPI Description Table (FADT)]

quoted

quoted

[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.

FYI, a hack like below seems working.


Takashi

---

diff --git a/drivers/input/serio/i8042-x86ia64io.h

b/drivers/input/serio/i8042-x86ia64io.h

quoted

index 073246c7d163..ed6ab702e4b7 100644

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h

@@ -9,6 +9,7 @@
 
 #ifdef CONFIG_X86
 #include <asm/x86_init.h>
+#include <linux/acpi.h>
 #endif
 
 /*

@@ -1055,6 +1056,13 @@ static int __init i8042_pnp_init(void)
 #if defined(__ia64__)
 		return -ENODEV;
 #else
+#ifdef CONFIG_ACPI
+		if (acpi_gbl_FADT.header.revision >= 3 &&
+		    !(acpi_gbl_FADT.boot_flags & ACPI_FADT_8042)) {
+			pr_info("PNP: No PS/2 controller found and disabled in ACPI\n");
+			return -ENODEV;
+		}
+#endif
 		pr_info("PNP: No PS/2 controller found. Probing ports

directly.\n");

quoted

 		return 0;
 #endif

I'm not an expert in any subsystem but, maybe this "hack" could be
added
to default_i8042_detect in arch/x86/kernel/x86_init.c? Currently it is
enabled by default, but different Intel platform like ce4100 and
intel-mid disables it explicit.

I mentioned "hack" because following osdev.org[1] using ACPI is the
correct way to detect if i8042 exists. Pardon me if this not applies in
this situation, or if I missed something.

That is the proper way of detecting i8042 if you trust firmware; historically we do not, and so we want to make sure that PNP data agrees with fadt data.

So it depends on how well you trust the firmware.  If we assume ACPI
providing always correctly, it can be put in default_i8042_detect, and
it'd be a better place indeed.  OTOH, if we don't trust ACPI,
especially on older machines, and let at first probing ACPI PnP no
matter whether FADT bit is set, we'd need to put the check after PnP
probe like my patch.

My patch assumes that the BIOS is new and good enough if FADT revision
is 3 or greater.  The only concern is whether this is really good
enough.  I just hope so.

In anyway, Dmitry, if you're happy with it, I'll cook up the proper
patch for the merge.  Let me know.


thanks,

Takashi