From patchwork Wed Apr 13 16:50:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Heitor Alves de Siqueira X-Patchwork-Id: 1616855 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=tRKAVdPf; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KdpW03zSWz9sGS for ; Thu, 14 Apr 2022 02:50:36 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1negCN-0002B1-7v; Wed, 13 Apr 2022 16:50:31 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1negCK-0002AF-Q7 for kernel-team@lists.ubuntu.com; Wed, 13 Apr 2022 16:50:28 +0000 Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 12FD23F157 for ; Wed, 13 Apr 2022 16:50:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1649868628; bh=RIU6CSbenijkgDRryq1J7t/Ilm9QnD1vhRVLCTYj4AA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=tRKAVdPfERUkmY7aa8BQiCDddyydbZ8sZ3YSGXS2gP4w10SyQDrBDcsbYlGSdaGyw y03NWRAcUX6ObYJxlkoQmxTooqaf6gjr8+3N1FULFZqsFfGNuJ7b//rrgvZn9gyOpt p8ZEhFGA/36NjOojMHHrp8xJthQ6i1bUL9gF5jYf+Rfa0WuI/gaNwHksqJmqkL+mUI iK+5KCgy3sjvF0du0+YNmXkfaWqBG7xC6RdWeeVE+p6Z+9mh2JIuNaXgd2xdS/ymV9 xHeBE/zewaHegQ+oclSD9tz+9Apm4JxYhZ9drWblLHLvtJN5rfP4hyXoPtpJtXwBz6 8eYszN0S4yeMA== Received: by mail-oi1-f198.google.com with SMTP id c11-20020aca1c0b000000b002da42e09f96so1093192oic.1 for ; Wed, 13 Apr 2022 09:50:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RIU6CSbenijkgDRryq1J7t/Ilm9QnD1vhRVLCTYj4AA=; b=GoI/Q1bvJEzJMQ9kkVXAG+hxsxtCQWdtUQNmsxwL9Ci8PyXC+k2f1C+T9bsVTbLR2u 6+9kv4EFuwwCClnyINz3kwFvYx/Wj6Kn2yCfANFP6DkO2f65fhLycaF+6V+GtVq62toQ ii5wMdOEBd/boyj9z46AxCC+rfyTjClXqbh1eq5B/qzhetmo6RMjBqsi8REWKWyIpOw6 ZQrkUFxvlJoPb1iCz30ZYAvfD23F2RJ6T1uthomhCKk9SmpVigsWLAremWduDO0aqy+R Raf5TUtHy+/Eq0XUWZC0//GxLnOdGpxxnFmEt9ExvsZgj38a0bvJwV0afjoc1R03jRrv DN4w== X-Gm-Message-State: AOAM530Ia32mlPJixwxfkthso3idoH11dD7JIGqNKjPqBKj+9WwY52It mFjmRYWKhQYxyfuoIH6oUdU8BERcYN6bF8EHko3C+QoKMx9GDrKDQOvt/CzfgfGDBAo7ay+KfUK 3k1w6VamJJcOaaxwussnhemh0ZlrdM6i7zePKNrwyrg== X-Received: by 2002:a05:6808:30a5:b0:2da:4dd3:a02d with SMTP id bl37-20020a05680830a500b002da4dd3a02dmr4538822oib.251.1649868625914; Wed, 13 Apr 2022 09:50:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrP2telqy/XIlD2ieMxQFiP2yLJ9xgO6iPszv4Slj/V5J9SGWYVpTvSQTIoMoOQUMNRbZtkg== X-Received: by 2002:a05:6808:30a5:b0:2da:4dd3:a02d with SMTP id bl37-20020a05680830a500b002da4dd3a02dmr4538807oib.251.1649868625540; Wed, 13 Apr 2022 09:50:25 -0700 (PDT) Received: from sonoran.. ([2804:431:cfea:8429::436]) by smtp.gmail.com with ESMTPSA id h11-20020a9d6f8b000000b005b230ab0461sm14695563otq.64.2022.04.13.09.50.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 09:50:25 -0700 (PDT) From: Heitor Alves de Siqueira To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/2] [SRU][impish] ACPI: power: Rework turning off unused power resources Date: Wed, 13 Apr 2022 13:50:15 -0300 Message-Id: <20220413165017.360226-2-halves@canonical.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220413165017.360226-1-halves@canonical.com> References: <20220413165017.360226-1-halves@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heitor Alves de Siqueira Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: "Rafael J. Wysocki" BugLink: https://bugs.launchpad.net/bugs/1942624 Make turning off unused power resources (after the enumeration of devices and during system-wide resume from S3) more straightforward by using the observation that the power resource state stored in struct acpi_power_resource can be used to determine whether or not the give power resource has any users. Namely, when the state of the power resource is unknown, its _STA method has never been evaluated (or the evaluation of it has failed) and its _ON and _OFF methods have never been executed (or they have failed to execute), so for all practical purposes it can be assumed to have no users (or to be unusable). Therefore, instead of checking the number of power resource users, it is sufficient to check if its state is known. Moreover, if the last known state of a given power resource is "off", it is not necessary to turn it off, because it has been used to initialize the power state or the wakeup power resources list of at least one device and either its _STA method has returned 0 ("off"), or its _OFF method has been successfully executed already. Accordingly, modify acpi_turn_off_unused_power_resources() to do the above checks (which are suitable for both uses of it) instead of using the number of power resource users or evaluating its _STA method, drop its argument (which is not useful any more) and update its callers. Also drop the users field from struct acpi_power_resource as it is not useful any more. Tested-by: Dave Olsthoorn Tested-by: Shujun Wang Signed-off-by: Rafael J. Wysocki (backported from commit 6381195ad7d06ef979528c7452f3ff93659f86b1) Signed-off-by: Heitor Alves de Siqueira --- drivers/acpi/internal.h | 2 +- drivers/acpi/power.c | 52 +++++++++++++++-------------------------- drivers/acpi/scan.c | 2 +- drivers/acpi/sleep.c | 2 +- 4 files changed, 22 insertions(+), 36 deletions(-) diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h index 8feb31d53edd..e71ff3ef9e73 100644 --- a/drivers/acpi/internal.h +++ b/drivers/acpi/internal.h @@ -142,7 +142,7 @@ int acpi_device_sleep_wake(struct acpi_device *dev, int acpi_power_get_inferred_state(struct acpi_device *device, int *state); int acpi_power_on_resources(struct acpi_device *device, int state); int acpi_power_transition(struct acpi_device *device, int state); -void acpi_turn_off_unused_power_resources(bool init); +void acpi_turn_off_unused_power_resources(void); /* -------------------------------------------------------------------------- Device Power Management diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index 97c9a94a1a30..0632a224e0a2 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -52,7 +52,6 @@ struct acpi_power_resource { u32 system_level; u32 order; unsigned int ref_count; - unsigned int users; bool wakeup_enabled; struct mutex resource_lock; struct list_head dependents; @@ -173,8 +172,6 @@ int acpi_extract_power_resources(union acpi_object *package, unsigned int start, err = acpi_power_resources_list_add(rhandle, list); if (err) break; - - to_power_resource(rdev)->users++; } if (err) acpi_power_resources_list_free(list); @@ -1002,47 +999,36 @@ void acpi_resume_power_resources(void) } #endif -static void acpi_power_turn_off_if_unused(struct acpi_power_resource *resource, - bool init) -{ - if (resource->ref_count > 0) - return; - - if (init) { - if (resource->users > 0) - return; - } else { - int result, state; - - result = acpi_power_get_state(resource->device.handle, &state); - if (result || state == ACPI_POWER_RESOURCE_STATE_OFF) - return; - } - - dev_info(&resource->device.dev, "Turning OFF\n"); - __acpi_power_off(resource); -} - /** * acpi_turn_off_unused_power_resources - Turn off power resources not in use. - * @init: Control switch. - * - * If @ainit is set, unconditionally turn off all of the ACPI power resources - * without any users. - * - * Otherwise, turn off all ACPI power resources without active references (that - * is, the ones that should be "off" at the moment) that are "on". */ -void acpi_turn_off_unused_power_resources(bool init) +void acpi_turn_off_unused_power_resources(void) { struct acpi_power_resource *resource; mutex_lock(&power_resource_list_lock); list_for_each_entry_reverse(resource, &acpi_power_resource_list, list_node) { + int result, state; + mutex_lock(&resource->resource_lock); - acpi_power_turn_off_if_unused(resource, init); + result = acpi_power_get_state(resource->device.handle, &state); + if (result) { + mutex_unlock(&resource->resource_lock); + continue; + } + + /* + * Turn off power resources in an unknown state too, because the + * platform firmware on some system expects the OS to turn off + * power resources without any users unconditionally. + */ + if (!resource->ref_count && + state != ACPI_POWER_RESOURCE_STATE_OFF) { + dev_info(&resource->device.dev, "Turning OFF\n"); + __acpi_power_off(resource); + } mutex_unlock(&resource->resource_lock); } diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 3c7813c9da02..1f71c357a120 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -2363,7 +2363,7 @@ int __init acpi_scan_init(void) } } - acpi_turn_off_unused_power_resources(true); + acpi_turn_off_unused_power_resources(); acpi_scan_initialized = true; diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index a6efb32dea6a..0b5e6580057a 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -504,7 +504,7 @@ static void acpi_pm_start(u32 acpi_state) */ static void acpi_pm_end(void) { - acpi_turn_off_unused_power_resources(false); + acpi_turn_off_unused_power_resources(); acpi_scan_lock_release(); /* * This is necessary in case acpi_pm_finish() is not called during a From patchwork Wed Apr 13 16:50:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Heitor Alves de Siqueira X-Patchwork-Id: 1616858 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=HRVCizzL; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KdpW35LSdz9sGF for ; Thu, 14 Apr 2022 02:50:39 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1negCQ-0002E6-L3; Wed, 13 Apr 2022 16:50:34 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1negCO-0002Bu-Tc for kernel-team@lists.ubuntu.com; Wed, 13 Apr 2022 16:50:32 +0000 Received: from mail-ot1-f71.google.com (mail-ot1-f71.google.com [209.85.210.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 1B9ED3F1CE for ; Wed, 13 Apr 2022 16:50:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1649868632; bh=u3BVofiQKp134CvSuq1yPJDzBO7p0LRHBZPs5JGp0aQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=HRVCizzLz1OZaWhYV/UX6fwXmXAjvnJnkNARroLzK33iMKw/9DeC/khsjFXe0l4d/ /NrdP1Peo0BNswu94+w+RGygAR1Weds/BaDYLbqNt6ZfyFo2/xsfHdgURMcVRSelLq R2WreOJukyVhN2wowdjHPgn8vyBxFjvMOT8lW6OE/cc3V63wvpSyVNlqs1LeHBuvUD yULYQxH+gbkEWfh8SzAb+j44ykwStO3FprvPZjWFGuocLgB1Z/ybEozNJI/QMgr0An +UCR48V4K9w6HHgK5yqj/IIJ5WtfdqaizBAblrmfvm+NcIvUKZbfAEHxX3ynF4paeY jBXKkJZCFBT5Q== Received: by mail-ot1-f71.google.com with SMTP id l38-20020a0568302b2600b005e8965b82edso1227529otv.15 for ; Wed, 13 Apr 2022 09:50:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=u3BVofiQKp134CvSuq1yPJDzBO7p0LRHBZPs5JGp0aQ=; b=SInU+gKxkWEJT0UZegKWJjJJq1PlHCLWnH4EdT5TdCJoErOnjE9pvB+bUrJjlK8PiF SNtuBYEgryvszEWTdIHsYgIMPlxSzTdP1T8RfXTwS5dZuOuiUH7C3IvB/ZQmcosxxBQC icKp54TXfPjs2y5IHh9tj6Rfij2K39kXCNRD4NPvjBd2YBXZIrNBhKU8QPvyiWO37BiC 2+9BgdR4uN1b8CgQioJe5AiwoUEyNw1tgF5sr75uFkIsYfH4+7XROCGiHg6Ykd61bl3B Nzj1LjZXf5pFJcNx0+5WctsuqYEXaoEIBSmyT9bc8cWXCIqhkdkdPkg3jge1KChgyGRt Kf3w== X-Gm-Message-State: AOAM533mOoTUTSUETjNKZnMJ7rwckf+WoWXpdyPQSZtDuJadIKUrPP9B g9tk4SmTc9Vw40Mz4yq04R3xEeIRTRUJldHXMTiORwNGE/Bxe6BWLHMszRr+BIKsmWtHXpuUO5u IjOFDWysekDS0TcceLrC8KPa6/0z/mzFkaCcwuh9qiQ== X-Received: by 2002:a9d:69:0:b0:5c9:3456:f02f with SMTP id 96-20020a9d0069000000b005c93456f02fmr15531625ota.25.1649868630519; Wed, 13 Apr 2022 09:50:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhRkiKO4CpYUFWGdU9OpNKXfXCAGpObVC4TFgjDk0VRZuzOzrWUaMkWYjRAc3VS0K230Cl4g== X-Received: by 2002:a9d:69:0:b0:5c9:3456:f02f with SMTP id 96-20020a9d0069000000b005c93456f02fmr15531611ota.25.1649868630217; Wed, 13 Apr 2022 09:50:30 -0700 (PDT) Received: from sonoran.. ([2804:431:cfea:8429::436]) by smtp.gmail.com with ESMTPSA id h11-20020a9d6f8b000000b005b230ab0461sm14695563otq.64.2022.04.13.09.50.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 09:50:29 -0700 (PDT) From: Heitor Alves de Siqueira To: kernel-team@lists.ubuntu.com Subject: [PATCH 2/2] [SRU][impish] ACPI: PM: Do not turn off power resources in unknown state Date: Wed, 13 Apr 2022 13:50:17 -0300 Message-Id: <20220413165017.360226-4-halves@canonical.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220413165017.360226-1-halves@canonical.com> References: <20220413165017.360226-1-halves@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heitor Alves de Siqueira Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: "Rafael J. Wysocki" BugLink: https://bugs.launchpad.net/bugs/1942624 Commit 6381195ad7d0 ("ACPI: power: Rework turning off unused power resources") caused power resources in unknown state with reference counters equal to zero to be turned off too, but that caused issues to appear in the field, so modify the code to only turn off power resources that are known to be "on". Link: https://lore.kernel.org/linux-acpi/6faf4b92-78d5-47a4-63df-cc2bab7769d0@molgen.mpg.de/ Fixes: 6381195ad7d0 ("ACPI: power: Rework turning off unused power resources") Reported-by: Andreas K. Huettel Tested-by: Andreas K. Huettel Signed-off-by: Rafael J. Wysocki Cc: 5.14+ # 5.14+ (backported from commit bc28368596436e6e81ffc48c815b8225d96121c0) Signed-off-by: Heitor Alves de Siqueira --- drivers/acpi/power.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index 0632a224e0a2..8e045dcaed8d 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -1019,13 +1019,8 @@ void acpi_turn_off_unused_power_resources(void) continue; } - /* - * Turn off power resources in an unknown state too, because the - * platform firmware on some system expects the OS to turn off - * power resources without any users unconditionally. - */ if (!resource->ref_count && - state != ACPI_POWER_RESOURCE_STATE_OFF) { + state == ACPI_POWER_RESOURCE_STATE_ON) { dev_info(&resource->device.dev, "Turning OFF\n"); __acpi_power_off(resource); }