From patchwork Tue Jan 2 16:08:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 10140967 X-Patchwork-Delegate: geert@linux-m68k.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 616D760594 for ; Tue, 2 Jan 2018 16:09:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4B83A28B67 for ; Tue, 2 Jan 2018 16:09:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3E0A728433; Tue, 2 Jan 2018 16:09:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DC8F128433 for ; Tue, 2 Jan 2018 16:09:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751095AbeABQJC (ORCPT ); Tue, 2 Jan 2018 11:09:02 -0500 Received: from mail-lf0-f65.google.com ([209.85.215.65]:45465 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751066AbeABQJB (ORCPT ); Tue, 2 Jan 2018 11:09:01 -0500 Received: by mail-lf0-f65.google.com with SMTP id y71so5094058lfd.12 for ; Tue, 02 Jan 2018 08:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=2TkJwObSBzzfwZ33Q+ifKvh0/A+ZHvasaCfRCMgstgI=; b=D1HuTXIeI1elawHYSa1o09S06AUZHZY3lWSLwcIvcqNv3HpEdrKBMuLLRo3ZPjFpRF CRGOiOq443Fym8O28L5ICrRQui9ROYQY+WP++u4hbpjtiCauNDAejE5EDRY2rpUQWURS uTYfJcAVZhr8WQz3DETqOsyTxR29FUDM4yjhg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=2TkJwObSBzzfwZ33Q+ifKvh0/A+ZHvasaCfRCMgstgI=; b=C3jhfHVdSGG4xvOSmvXeX2a1TR6BY+aK5GbL29rcSgiMs38qZ1R5ooHAKgQqSw+bEk 71ZsJazrDnmwzqIwdQqnyx0mN1NZWrVkGl6Nc8mI7Gb9zBR89x+ebo/wGJDjVwZqdb9K zDsnp//PvOUCLOQKyF8CVnkDhj3bgdGYxYA6C3wOdPkSA8T4pOYgeZHJgnRrzjk+E0Kv SweVly/5v0nmjlc+JQj88tdUDuB/tso1Dp7fyEk1thzcEMPxc2m8D+lYlNCH9p3wb37m 1aDYDD1Wf1MpOKnFk441ztr2vsgKGL9A73S0WF6lY7GgnAzJgG0Aor6/eYMDl2YS7RRe XXHA== X-Gm-Message-State: AKGB3mJwxekgmCf9ULw9+gai0GE1eQz93EPzL21QpbhMKGsMsCtbBFhR D+PHrytdn5oHrnmSaTPsQBBXWw== X-Google-Smtp-Source: ACJfBouYDUz0IS3colNOO+fknCZg/6Hf51TMsINg4FQVagwWJAgGO0i9F1xu22WhMV58k9bK0jQauQ== X-Received: by 10.25.150.8 with SMTP id y8mr2074435lfd.49.1514909340125; Tue, 02 Jan 2018 08:09:00 -0800 (PST) Received: from localhost.localdomain (h-158-174-22-67.NA.cust.bahnhof.se. [158.174.22.67]) by smtp.gmail.com with ESMTPSA id f4sm1619422lfl.17.2018.01.02.08.08.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Jan 2018 08:08:59 -0800 (PST) From: Ulf Hansson To: "Rafael J . Wysocki" , linux-pm@vger.kernel.org Cc: Kevin Hilman , Viresh Kumar , Geert Uytterhoeven , Simon Horman , Niklas Soderlund , Vincent Guittot , linux-renesas-soc@vger.kernel.org, Ulf Hansson Subject: [PATCH v3 1/4] PM / core: Assign the wakeup_path status flag in __device_prepare() Date: Tue, 2 Jan 2018 17:08:50 +0100 Message-Id: <1514909333-4450-2-git-send-email-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1514909333-4450-1-git-send-email-ulf.hansson@linaro.org> References: <1514909333-4450-1-git-send-email-ulf.hansson@linaro.org> Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The PM core in the device_prepare() phase, resets the wakeup_path status flag to the value of device_may_wakeup(). This means if a ->prepare() or a ->suspend() callback for the device would update the device's wakeup setting, this doesn't become reflected in the wakeup_path status flag. In general this isn't a problem, because wakeup settings are not supposed to be changed (via for example calling device_set_wakeup_enable()) during any system wide suspend/resume phase. Nevertheless there are some users, which can be considered as legacy, that don't conform to this behaviour. These legacy cases should be corrected, however until that is done, let's address the issue from the PM core, by moving the assignment of the wakeup_path status flag to the __device_suspend() phase and after the ->suspend() callback has been invoked. Signed-off-by: Ulf Hansson --- drivers/base/power/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index 70398e7..7aeb91d 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1788,6 +1788,8 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async) End: if (!error) { dev->power.is_suspended = true; + if (device_may_wakeup(dev)) + dev->power.wakeup_path = true; dpm_propagate_to_parent(dev); dpm_clear_suppliers_direct_complete(dev); } @@ -1912,7 +1914,7 @@ static int device_prepare(struct device *dev, pm_message_t state) device_lock(dev); - dev->power.wakeup_path = device_may_wakeup(dev); + dev->power.wakeup_path = false; if (dev->power.no_pm_callbacks) { ret = 1; /* Let device go direct_complete */