From patchwork Wed Apr 10 09:55:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 1083276 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="LXkahYLK"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 44fKKT3ZGPz9s4V for ; Wed, 10 Apr 2019 19:55:41 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730261AbfDJJz3 (ORCPT ); Wed, 10 Apr 2019 05:55:29 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:43243 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730256AbfDJJz2 (ORCPT ); Wed, 10 Apr 2019 05:55:28 -0400 Received: by mail-lj1-f196.google.com with SMTP id f18so1490108lja.10 for ; Wed, 10 Apr 2019 02:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=IdJSlX082YGa+o2RjrcHVg2ClWPcfT2dSVotJi56VHg=; b=LXkahYLKzcDWcov3EhmrnSqF7l0ZXLldbNSWy+3WOKivzEWNVsDEMAc/w1fGAJ0d+S jU+gZtakF/P20vRD0HTjJydZ0aodQzLjGq1sxd7k7PMNOCTsAYwSdIMuxElevBFQbOsE oelE3y3dezV9zqaCi//YyPIEGhlmkX6pCoER0fRz9WRyqRXOToansJreNKndeL0vud5f MtXOSNFAk98IV0gHyxqzBdceik6Fls+cTt+p7vAbsGxieUdDdkJRRuH0YIjLomA8qS9F B1UBFGwoqaeC9YQZFqO0vnTdET8iiYBdIq6ceOmemhmAz+LCCRV1JpTdrL+YS8+RjKWS Lvww== 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; bh=IdJSlX082YGa+o2RjrcHVg2ClWPcfT2dSVotJi56VHg=; b=JuUU4CdXFKzc95OboyNa9JfBHF9PQZAaK5vgVXjPcKhKHut93wjyGoJYGExNMrU2dz bAX4ZnZcX2y9tIMhhtQCvkU9/cf44ZPB529DkHjKy7l2scsyORQGGIpVw5rgDSszYCW3 gJ5rrPgjYruqDFudwSTJghi81GjmiJb2BpaDP9hRrK9ppImYSaBvOl8efQk779Q0lOH/ RxFVqBYJ6IgrHX6pZE1QSukG9lL83tdINVkpAJ3fvhHhZ/EavvO/+RT1unSbZjEcsqdY xUVW4FcZvEhritVHnmpCborMBQd+kXfVnrc411EmIhlzAFHB5CNoUN3NAzwfJSPYd5yj 6lIA== X-Gm-Message-State: APjAAAXwHJbh//k2WddksB/xKlXsF8okpiV0cJMgkF39qD+YTD0XW+2F IWmI/g8niubYBJs914CoEwQKfA== X-Google-Smtp-Source: APXvYqwk7081QudqCuERp6RleVPoGeEKggtgjEdb4dksKdX/YeywMTxgd+NhOrUbEYXQ2jg1bnL9HA== X-Received: by 2002:a2e:9013:: with SMTP id h19mr16508925ljg.136.1554890126771; Wed, 10 Apr 2019 02:55:26 -0700 (PDT) Received: from localhost.localdomain (h-158-174-22-210.NA.cust.bahnhof.se. [158.174.22.210]) by smtp.gmail.com with ESMTPSA id h3sm113941lfe.87.2019.04.10.02.55.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 02:55:26 -0700 (PDT) From: Ulf Hansson To: "Rafael J . Wysocki" , linux-pm@vger.kernel.org Cc: Geert Uytterhoeven , Loic Pallardy , Linus Walleij , Alexandre Torgue , Rob Herring , Greg Kroah-Hartman , Johan Hovold , linux-gpio@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Ulf Hansson Subject: [PATCH] PM / core: Propagate dev->power.wakeup_path when no callbacks Date: Wed, 10 Apr 2019 11:55:16 +0200 Message-Id: <20190410095516.6170-1-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.17.1 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org The dev->power.direct_complete flag may become set in device_prepare() in case the device don't have any PM callbacks (dev->power.no_pm_callbacks is set). This leads to a broken behaviour, when there is child having wakeup enabled and relies on its parent to be used in the wakeup path. More precisely, when the direct complete path becomes selected for the child in __device_suspend(), the propagation of the dev->power.wakeup_path becomes skipped as well. Let's address this problem, by checking if the device is a part the wakeup path or has wakeup enabled, then prevent the direct complete path from being used. Reported-by: Loic Pallardy Signed-off-by: Ulf Hansson --- More background: This problem was reported by Loic Pallardy, offlist, while he was working on enabling wakeup for a tty serial console driver. When I looked more closely, I noticed that uart_suspend_port() calls device_may_wakeup() for the tty child devices, and then also the used serial driver check its device (parent) for device_may_wakeup(). To me this looks like workarounds to fix a behaviour that really should be dealt with from the PM core, no matter of whether the child have PM callbacks assigned or not. In other words, it seems like the serial driver(s) should be checking the wakeup_path flag for the parent, solely, instead. I haven't digested further behaviours for other subsystem, but recently reviewed a patch for a gpio driver [1], that seems to be suffering from the similar problems. Kind regards Ulf Hansson [1] https://lkml.org/lkml/2019/4/4/1283 --- drivers/base/power/main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index 41eba82ee7b9..f9cfdeee8288 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1747,6 +1747,10 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async) if (dev->power.syscore) goto Complete; + /* Avoid direct_complete, to let wakeup_path being propagated. */ + if (device_may_wakeup(dev) || dev->power.wakeup_path) + dev->power.direct_complete = false; + if (dev->power.direct_complete) { if (pm_runtime_status_suspended(dev)) { pm_runtime_disable(dev);