Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755802AbcCCUf5 (ORCPT ); Thu, 3 Mar 2016 15:35:57 -0500 Received: from mail-pa0-f48.google.com ([209.85.220.48]:34431 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752044AbcCCUfz (ORCPT ); Thu, 3 Mar 2016 15:35:55 -0500 From: Kevin Hilman To: Laurent Pinchart Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , Len Brown , Pavel Machek , linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended Organization: BayLibre References: <1457036214-26136-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> Date: Thu, 03 Mar 2016 12:35:53 -0800 In-Reply-To: <1457036214-26136-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> (Laurent Pinchart's message of "Thu, 3 Mar 2016 22:16:54 +0200") Message-ID: <7hwppjuwnq.fsf@baylibre.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1529 Lines: 40 Laurent Pinchart writes: > The pm_runtime_force_suspend() and pm_runtime_force_resume() helpers are > designed to help driver being RPM-centric by offering an easy way to > manager runtime PM state during system suspend and resume. The first s/manager/manage/ > function will force the device into runtime suspend at system suspend > time, while the second one will perform the reverse operation at system > resume time. > > However, the pm_runtime_force_resume() really forces resume, regarding s/regarding/regardless/ > of whether the device was running or already suspended before the call > to pm_runtime_force_suspend(). This results in devices being runtime > resumed at system resume time when they shouldn't. Agreed. > Fix this by recording whether the device has been forcefully suspended > in pm_runtime_force_suspend() and condition resume in > pm_runtime_force_resume() to that state. > > All current users of pm_runtime_force_resume() call the function > uncontionally in their system resume handler (some actually set it as > the resume handler), all after calling pm_runtime_force_suspend() at > system suspend time. The change in behaviour should thus be safe. > > Signed-off-by: Laurent Pinchart Reviewed-by: Kevin Hilman I agree this is the right approach, but Ulf should ack this too since he's looked into all the strange corner case involved and may know of something I've missed. Kevin