From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751668AbdF2XMF (ORCPT ); Thu, 29 Jun 2017 19:12:05 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:60049 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751560AbdF2XME (ORCPT ); Thu, 29 Jun 2017 19:12:04 -0400 From: "Rafael J. Wysocki" To: Florian Fainelli Cc: linux-kernel@vger.kernel.org, Alexandre Belloni , "Rafael J. Wysocki" , Ulf Hansson , Daniel Lezcano , linux-pm , Thibaud Cornic , JB , Mason , Kevin Hilman , Pavel Machek , Linux ARM Subject: Re: [RFC 2/2] soc: bcm: brcmstb: PM: Implement target_state callback Date: Fri, 30 Jun 2017 01:04:35 +0200 Message-ID: <48358346.FqHa0fcY05@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.12.0-rc1+; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20170623010837.11199-3-f.fainelli@gmail.com> References: <20170622085102.mpk7vxodpgxtrlfd@piout.net> <20170623010837.11199-1-f.fainelli@gmail.com> <20170623010837.11199-3-f.fainelli@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, June 22, 2017 06:08:37 PM Florian Fainelli wrote: > Provide a target_state callback implementation which just returns the > suspend_state_t the system is about to enter. Broadcom STB drivers can > utilize platform_suspend_target_state() to retrieve that and take > appropriate actions (e.g: full vs. partial re-initialization). > > Signed-off-by: Florian Fainelli > --- > drivers/soc/bcm/brcmstb/pm/pm-arm.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/soc/bcm/brcmstb/pm/pm-arm.c b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > index 4b7e6c297b23..7d4695734093 100644 > --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c > +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > @@ -104,6 +104,7 @@ struct brcmstb_pm_control { > u32 phy_b_standby_ctrl_offs; > bool needs_ddr_pad; > struct platform_device *pdev; > + suspend_state_t pm_state; I wouldn't use suspend_state_t here, because the mapping between those things and real platform power states is somewhat arbitrary and totally platform-specific. It's better to define symbols representing platform power states for your platform (or use an enum) and then use those symbols in the drivers IMO. Thanks, Rafael From mboxrd@z Thu Jan 1 00:00:00 1970 From: rjw@rjwysocki.net (Rafael J. Wysocki) Date: Fri, 30 Jun 2017 01:04:35 +0200 Subject: [RFC 2/2] soc: bcm: brcmstb: PM: Implement target_state callback In-Reply-To: <20170623010837.11199-3-f.fainelli@gmail.com> References: <20170622085102.mpk7vxodpgxtrlfd@piout.net> <20170623010837.11199-1-f.fainelli@gmail.com> <20170623010837.11199-3-f.fainelli@gmail.com> Message-ID: <48358346.FqHa0fcY05@aspire.rjw.lan> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday, June 22, 2017 06:08:37 PM Florian Fainelli wrote: > Provide a target_state callback implementation which just returns the > suspend_state_t the system is about to enter. Broadcom STB drivers can > utilize platform_suspend_target_state() to retrieve that and take > appropriate actions (e.g: full vs. partial re-initialization). > > Signed-off-by: Florian Fainelli > --- > drivers/soc/bcm/brcmstb/pm/pm-arm.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/soc/bcm/brcmstb/pm/pm-arm.c b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > index 4b7e6c297b23..7d4695734093 100644 > --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c > +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > @@ -104,6 +104,7 @@ struct brcmstb_pm_control { > u32 phy_b_standby_ctrl_offs; > bool needs_ddr_pad; > struct platform_device *pdev; > + suspend_state_t pm_state; I wouldn't use suspend_state_t here, because the mapping between those things and real platform power states is somewhat arbitrary and totally platform-specific. It's better to define symbols representing platform power states for your platform (or use an enum) and then use those symbols in the drivers IMO. Thanks, Rafael