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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4773EC433F5 for ; Thu, 13 Jan 2022 11:44:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232173AbiAMLoY (ORCPT ); Thu, 13 Jan 2022 06:44:24 -0500 Received: from mga07.intel.com ([134.134.136.100]:27867 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232038AbiAMLoY (ORCPT ); Thu, 13 Jan 2022 06:44:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642074264; x=1673610264; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=suzZ8EqddoFsx9Y4MQoKzgw94R2NGTJ7PLafmjJ4+hw=; b=WlJTGTdQFKBhjvoQQdyTxmHDM4GybnPxdIfz1M9GJa8GAKs0UriXam0I 86Q9Is7ysuhwt8ODLW2XZcqb57FvHLfPGt7VZkiKFLV8dblcb7akipwGT dffzZbxxAqfqo1l2/PAhVf43eiWNuDL6FbLju2XmqOepyBe8HfHbPYxzS /4giSiUQrD8MmSkHw69SlEcmyc07iFFC3gKnIKlew/faoDV6dnp9hBY+k Xyq+X4mj+nORHNE9cx7HihL0ydAl5Aw3SW17YAMMldmDez45DMWcMtzbp IMQtQZbB1w/UGYOpN4FrVpJoQX9PZDIqEbvPHubI08EY3iIBzd2cW1/za w==; X-IronPort-AV: E=McAfee;i="6200,9189,10225"; a="307336360" X-IronPort-AV: E=Sophos;i="5.88,284,1635231600"; d="scan'208";a="307336360" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2022 03:44:23 -0800 X-IronPort-AV: E=Sophos;i="5.88,284,1635231600"; d="scan'208";a="691773606" Received: from smile.fi.intel.com ([10.237.72.61]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2022 03:44:21 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1n7yVZ-00AAut-7i; Thu, 13 Jan 2022 13:43:09 +0200 Date: Thu, 13 Jan 2022 13:43:08 +0200 From: Andy Shevchenko To: Hans de Goede Cc: Mika Westerberg , Andy Shevchenko , Linus Walleij , linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org, Yauhen Kharuzhy Subject: Re: [PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device Message-ID: References: <20211118105650.207638-1-hdegoede@redhat.com> <20211118105650.207638-3-hdegoede@redhat.com> <654fd7f2-6ac3-6c4b-9710-0e6360935aa0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <654fd7f2-6ac3-6c4b-9710-0e6360935aa0@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Sat, Nov 27, 2021 at 10:49:55PM +0100, Hans de Goede wrote: > On 11/26/21 19:12, Andy Shevchenko wrote: > > On Thu, Nov 18, 2021 at 01:28:02PM +0200, Andy Shevchenko wrote: > >> On Thu, Nov 18, 2021 at 11:56:50AM +0100, Hans de Goede wrote: > >>> Many Cherry Trail DSDTs have an extra INT33FF device with UID 5, > >>> the intel_pinctrl_get_soc_data() call will fail for this extra > >>> unknown UID, leading to the following error in dmesg: > >>> > >>> cherryview-pinctrl: probe of INT33FF:04 failed with error -61 > >>> > >>> Add a check for this extra UID and return -ENODEV for it to > >>> silence this false-positive error message. > >> > >> Hmm... Interesting. Why do they have it? > >> Give me some time to check this... > > > > _DDN in ACPI describes this as Virtual GPIO. The only documentation at hand > > right now tells me that this is a "solution" to represent the "virtual GPIO" > > as fifth community (no connection to any pads, minimum configuration, etc). > > > > The goal as far as I can see is "to convert a PME event generated by PCI device > > to a GPIO interrupt". > > > > Seems like we better have a driver for it, but the only purpose of it is to > > generate interrupts based on PME. > > > > I'll try to dig more may be next week, but for now I would like to postpone the > > patch. Do you agree? > > Yes postponing merging this is fine. There is no hurry since this does > not fix anything broken. I just wanted to get rid of the annoying log message :) So, documentation says the following. "Chassis GPIO does not support the notion of Virtual GPIOs. So a fifth GPIO Community was added to provide virtual GPIOs. This virtual GPIO resides inside PCU." "Table 8‑19: Virtual GPIO Assignments in CHV GPIO-V[x] Usage [7] Reserved for PMC usage [6] PME handling [5] Reserved for PMC usage [4] OTG PME [3:1] In VLV2, was used for tx_modphy_common_mode_en. In CHV, these are reserved for future use. [0] SATA PME" IOAPIC mapping: "108 GPIO_virtual" While at it, in case you want the mapping for direct IRQ: 1) GPIO North: eight interrupts used, connected to IOxAPIC IRQ51 to IRQ58. 2) GPIO Southwest: eight interrupts used, connected to IOxAPIC IRQ59 to IRQ66. 3) GPIO East: all sixteen interrupts used, connected to IOxAPIC IRQ67 to IRQ82. 4) GPIO Southeast: all sixteen interrupt used, connected to IOxAPIC IRQ92 to IRQ107. -- With Best Regards, Andy Shevchenko