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 E0CABC54EAA for ; Mon, 23 Jan 2023 17:35:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231867AbjAWRf0 (ORCPT ); Mon, 23 Jan 2023 12:35:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232072AbjAWRfI (ORCPT ); Mon, 23 Jan 2023 12:35:08 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D191728F; Mon, 23 Jan 2023 09:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674495272; x=1706031272; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fvPh3dJY06YUKjJ7aZ8eKgwxiGrcXa9T/9Jejm0c1FY=; b=Ae+EuqPfHjQhkxGuApcqKshS/Zj1DFOuBDFwD0bycpzkPbyTwQG0EbQI IpWbIVyPt1xliOWuJqxIvgfrKHYpUfr9POpSPUHU9u430JrIUMIwKm+2x 4J2/6Fu9daE1KeeAaHZ1Gvk9p6NooHhE6tFYjPMTHw4KIpPkeAqVKRqdw sOD2shVVNB4TUDWVWDOiQ2VJQ+LKT30D/igLfZy4FicaqOBCHstUZZldY S19Y8HKYrR1X4aUcEpDj7yD82nFjMeoEcch+KK1SJ1KcrO/csHNqfCxQk DAm/my4R25feeIkuqHYieh/bcE8ALIV+2FwypAIOkSUASS2ksRwSQtjig A==; X-IronPort-AV: E=McAfee;i="6500,9779,10599"; a="323792869" X-IronPort-AV: E=Sophos;i="5.97,240,1669104000"; d="scan'208";a="323792869" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2023 09:33:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10599"; a="655089009" X-IronPort-AV: E=Sophos;i="5.97,240,1669104000"; d="scan'208";a="655089009" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 23 Jan 2023 09:33:29 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pK0hD-00DqwP-10; Mon, 23 Jan 2023 19:33:27 +0200 Date: Mon, 23 Jan 2023 19:33:27 +0200 From: Andy Shevchenko To: "Limonciello, Mario" Cc: Raul Rangel , Bartosz Golaszewski , Mika Westerberg , Linus Walleij , Dmitry Torokhov , Benjamin Tissoires , Wolfram Sang , "Rafael J. Wysocki" , Nathan Smythe , "linux-gpio@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Mark Hasemeyer Subject: Re: [PATCH 2/2] gpiolib-acpi: Don't set GPIOs for wakeup in S3 mode Message-ID: References: <20230121134812.16637-1-mario.limonciello@amd.com> <20230121134812.16637-3-mario.limonciello@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2023 at 04:06:59PM +0000, Limonciello, Mario wrote: > > From: Raul Rangel > > Sent: Monday, January 23, 2023 09:55 > > On Mon, Jan 23, 2023 at 8:03 AM Bartosz Golaszewski > > wrote: > > > On Sat, Jan 21, 2023 at 2:48 PM Mario Limonciello > > > wrote: ... > > > > + /* avoid suspend issues with GPIOs when systems are using > > S3 */ > > > > + if (wake_capable && acpi_gbl_FADT.flags & > > ACPI_FADT_LOW_POWER_S0) > > > > *wake_capable = info.wake_capable; > > > > > > > > return irq; ... > > We still need to figure out a proper fix for this. If you read my post > > here: https://gitlab.freedesktop.org/drm/amd/-/issues/2357#note_1732372 > > I think we misinterpreted what the SharedAndWake bit is used for. To > > me it sounds like it's only valid for HW Reduced ACPI platforms, and > > S0ix. My changes made it so we call `dev_pm_set_wake_irq` when the > > Wake bit is set. Does anyone have any additional context on the Wake > > bit? I think we either need to make `dev_pm_set_wake_irq` (or a > > variant) only enable the wake on S0i3, or we can teach the ACPI > > subsystem to manage arming the IRQ's wake bit. Kind of like we already > > manage the GPE events for the device. > > There is an FADT flag for HW reduced (ACPI_FADT_HW_REDUCED). So > maybe something on top of my change to look at that too? > > IE: > if (wake_capable && (acpi_gbl_FADT.flags & (ACPI_FADT_LOW_POWER_S0 | ACPI_FADT_HW_REDUCED) I'm not sure why we are talking about HW reduced case? In HP reduced case IIRC the GPE are absent as a class. -- With Best Regards, Andy Shevchenko