From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758071AbcLAHTv (ORCPT ); Thu, 1 Dec 2016 02:19:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:33175 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753413AbcLAHTt (ORCPT ); Thu, 1 Dec 2016 02:19:49 -0500 Date: Thu, 01 Dec 2016 08:19:46 +0100 Message-ID: From: Takashi Iwai To: Dmitry Torokhov Cc: Jiri Slaby , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: i8042 error at booting an Intel Cherry Trail-based device In-Reply-To: <20161201022923.GG31934@dtor-ws> References: <20161201022923.GG31934@dtor-ws> 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/24.5 (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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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