[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1787546.EYh03heFAd@aspire.rjw.lan>
Date: Sun, 16 Jul 2017 12:30:55 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: linux-kernel@...r.kernel.org,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-pm <linux-pm@...r.kernel.org>,
Thibaud Cornic <thibaud_cornic@...madesigns.com>,
JB <jb_lescher@...madesigns.com>, Mason <slash.tmp@...e.fr>,
Kevin Hilman <khilman@...nel.org>, Pavel Machek <pavel@....cz>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/2] PM / suspend: Add platform_suspend_target_state()
On Saturday, July 15, 2017 07:36:09 PM Florian Fainelli wrote:
> Add an optional platform_suspend_ops callback: target_state, and a
> helper function globally visible to get this called:
> platform_suspend_target_state().
>
> This is useful for platform specific drivers that may need to take a
> slightly different suspend/resume path based on the system's
> suspend/resume state being entered.
>
> Although this callback is optional and documented as such, it requires
> a platform_suspend_ops::begin callback to be implemented in order to
> provide an accurate suspend/resume state within the driver that
> implements this platform_suspend_ops.
>
> An enumeration: platform_target_state is defined which currently defines
> the standard ACPI_S[1-4] states and can be extended with platform
> specific suspend states.
This has a couple of problems, but I'm not sure if it is worth to go too much
into details here.
Let's just take a different approach as I said in the other thread.
Thanks,
Rafael
Powered by blists - more mailing lists