Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2044249pxb; Sun, 17 Oct 2021 04:32:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgFCxVw7kkt5DxzQ+fYjPP3A7OfS4l2zi4XqY0P7cRo+CPsioCckLlN7HXFLytK8nRpX+q X-Received: by 2002:a63:2dc7:: with SMTP id t190mr18150797pgt.455.1634470339926; Sun, 17 Oct 2021 04:32:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634470339; cv=none; d=google.com; s=arc-20160816; b=JJgUP/o3vM7vygbbnxSc9AWhZZWkliRBFMB0vXTHF8RBfxsmxCDVz7rsH0wz/12RMZ 4ZGvS/4hBLtDIdYIPDblt0jLsF6IuOIEoX1TKK1AHeXhoZVZGt3Hr5w8XK1QeShkAis7 X7ca0eauMSZnQ5ANhMHrdN0uVoE7oc8jpTC+vLLxYnv6lnHQEFLz/lNTyyiBjHiVBpF/ Ge1XgomZURl0eRrVVfnMz+SDx3zr+FtkCOHRoDFEsZibrwolyA3fIcOLl01jN7qGYwZh pTpj4RJRSOlQL+b0YO09+ilG/VvX+t6Zxr1bqrJZnrQm5nFvi40yaQm0tvD/dFQG5uik JbbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=vTOf1C2IhyQNZY1uIXDhveVKtQ1mD16jTWvVIFIvNEk=; b=xGWcIk1beGF703rJpI+wRNYzTnau9561WLIWPw7wBgAtBE/R4s7RiCpnWt7LnDnGA+ PXjj3Mk7C3+pO1luEnmbGCwppzSVTdSTCMdG4Ny1ipMNL73p/aEIyfZWQvYe0AXTWMTw YBp+/2xbH96NtMLItZlvrea+ZnSIKMGBZf+e20YuPhRkFr6oYSuOec3u74JvQ5/tBSJW WWSD2gZ7vPnykXnGzYTVqzDyBtJauEtxZ9bNG6Qcm3e2/QH2fEWY4cpbw4/COxxUvnRP Jdqwx+PooRuNKpPnQHZTR5xW8K98FLF25mUqHeQZVeu/1OSZytHyc1ad8v5ZutjSX8Ee 91iA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n18si21533323plf.303.2021.10.17.04.32.06; Sun, 17 Oct 2021 04:32:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241962AbhJORG6 (ORCPT + 99 others); Fri, 15 Oct 2021 13:06:58 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:64962 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241934AbhJORGz (ORCPT ); Fri, 15 Oct 2021 13:06:55 -0400 Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 3.0.0) id 168a8063eefe7ff3; Fri, 15 Oct 2021 19:04:48 +0200 Received: from kreacher.localnet (unknown [213.134.175.255]) (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 v370.home.net.pl (Postfix) with ESMTPSA id 4440566A8C0; Fri, 15 Oct 2021 19:04:47 +0200 (CEST) From: "Rafael J. Wysocki" To: Linux ACPI Cc: Linux PM , LKML , Mika Westerberg , Linux PCI Subject: [PATCH v1 2/3] ACPI: PM: Fix sharing of wakeup power resources Date: Fri, 15 Oct 2021 19:03:16 +0200 Message-ID: <2077987.irdbgypaU6@kreacher> In-Reply-To: <4347933.LvFx2qVVIh@kreacher> References: <4347933.LvFx2qVVIh@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 213.134.175.255 X-CLIENT-HOSTNAME: 213.134.175.255 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvtddrvddugedguddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdejlefghfeiudektdelkeekvddugfeghffggeejgfeukeejleevgffgvdeluddtnecukfhppedvudefrddufeegrddujeehrddvheehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddufedrudefgedrudejhedrvdehhedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqedprhgtphhtthhopehlihhnuhigqdgrtghpihesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehmihhkrgdrfigvshhtvghrsggvrhhgsehlihhnuhigrdhinhhtvghlrdgtohhmpdhrtghpthht oheplhhinhhugidqphgtihesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-DCC--Metrics: v370.home.net.pl 1024; Body=5 Fuz1=5 Fuz2=5 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki If an ACPI wakeup power resource is shared between multiple devices, it may not be managed correctly. Suppose, for example, that two devices, A and B, share a wakeup power resource P whose wakeup_enabled flag is 0 initially. Next, suppose that wakeup power is enabled for A and B, in this order, and disabled for B. When wakeup power is enabled for A, P will be turned on and its wakeup_enabled flag will be set. Next, when wakeup power is enabled for B, P will not be touched, because its wakeup_enabled flag is set. Now, when wakeup power is disabled for B, P will be turned off which is incorrect, because A will still need P in order to signal wakeup. Moreover, if wakeup power is enabled for A and then disabled for B, the latter will cause P to be turned off incorrectly (it will be still needed by A), because acpi_disable_wakeup_device_power() is allowed to manipulate power resources when the wakeup.prepare_count counter of the given device is 0. While the first issue could be addressed by changing the wakeup_enabled power resource flag into a counter, addressing the second one requires modifying acpi_disable_wakeup_device_power() to do nothing when the target device's wakeup.prepare_count reference counter is zero and that would cause the new counter to be redundant. Namely, if acpi_disable_wakeup_device_power() is modified as per the above, every change of the new counter following a wakeup.prepare_count change would be reflected by the analogous change of the main reference counter of the given power resource. Accordingly, modify acpi_disable_wakeup_device_power() to do nothing when the target device's wakeup.prepare_count reference counter is zero and drop the power resource wakeup_enabled flag altogether. While at it, ensure that all of the power resources that can be turned off will be turned off when disabling device wakeup due to a power resource manipulation error, to prevent energy from being wasted. Fixes: b5d667eb392e ("ACPI / PM: Take unusual configurations of power resources into account") Signed-off-by: Rafael J. Wysocki --- drivers/acpi/power.c | 73 ++++++++++++++++++--------------------------------- 1 file changed, 26 insertions(+), 47 deletions(-) Index: linux-pm/drivers/acpi/power.c =================================================================== --- linux-pm.orig/drivers/acpi/power.c +++ linux-pm/drivers/acpi/power.c @@ -52,7 +52,6 @@ struct acpi_power_resource { u32 order; unsigned int ref_count; u8 state; - bool wakeup_enabled; struct mutex resource_lock; struct list_head dependents; }; @@ -710,8 +709,7 @@ int acpi_device_sleep_wake(struct acpi_d */ int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state) { - struct acpi_power_resource_entry *entry; - int err = 0; + int err; if (!dev || !dev->wakeup.flags.valid) return -EINVAL; @@ -721,26 +719,13 @@ int acpi_enable_wakeup_device_power(stru if (dev->wakeup.prepare_count++) goto out; - list_for_each_entry(entry, &dev->wakeup.resources, node) { - struct acpi_power_resource *resource = entry->resource; - - mutex_lock(&resource->resource_lock); - - if (!resource->wakeup_enabled) { - err = acpi_power_on_unlocked(resource); - if (!err) - resource->wakeup_enabled = true; - } - - mutex_unlock(&resource->resource_lock); - - if (err) { - dev_err(&dev->dev, - "Cannot turn wakeup power resources on\n"); - dev->wakeup.flags.valid = 0; - goto out; - } + err = acpi_power_on_list(&dev->wakeup.resources); + if (err) { + dev_err(&dev->dev, "Cannot turn on wakeup power resources\n"); + dev->wakeup.flags.valid = 0; + goto out; } + /* * Passing 3 as the third argument below means the device may be * put into arbitrary power state afterward. @@ -763,46 +748,40 @@ int acpi_enable_wakeup_device_power(stru int acpi_disable_wakeup_device_power(struct acpi_device *dev) { struct acpi_power_resource_entry *entry; - int err = 0; + int err; if (!dev || !dev->wakeup.flags.valid) return -EINVAL; mutex_lock(&acpi_device_lock); - if (--dev->wakeup.prepare_count > 0) + if (dev->wakeup.prepare_count > 1) { + dev->wakeup.prepare_count--; goto out; + } - /* - * Executing the code below even if prepare_count is already zero when - * the function is called may be useful, for example for initialisation. - */ - if (dev->wakeup.prepare_count < 0) - dev->wakeup.prepare_count = 0; + /* Do nothing if wakeup power has not been enabled for this device. */ + if (!dev->wakeup.prepare_count) + goto out; err = acpi_device_sleep_wake(dev, 0, 0, 0); if (err) goto out; + /* + * All of the power resources in the list need to be turned off even if + * there are errors. + */ list_for_each_entry(entry, &dev->wakeup.resources, node) { - struct acpi_power_resource *resource = entry->resource; - - mutex_lock(&resource->resource_lock); - - if (resource->wakeup_enabled) { - err = acpi_power_off_unlocked(resource); - if (!err) - resource->wakeup_enabled = false; - } - - mutex_unlock(&resource->resource_lock); + int ret; - if (err) { - dev_err(&dev->dev, - "Cannot turn wakeup power resources off\n"); - dev->wakeup.flags.valid = 0; - break; - } + ret = acpi_power_off(entry->resource); + if (ret && !err) + err = ret; + } + if (err) { + dev_err(&dev->dev, "Cannot turn off wakeup power resources\n"); + dev->wakeup.flags.valid = 0; } out: