On Thu, Jun 22, 2017 at 5:18 PM, Florian Fainelli [off-list ref] wrote:

On 06/21/2017 05:03 PM, Rafael J. Wysocki wrote:

quoted

On Thu, Jun 22, 2017 at 1:55 AM, Florian Fainelli [off-list ref] wrote:

quoted

On 06/21/2017 03:57 PM, Rafael J. Wysocki wrote:

quoted

On Thu, Jun 22, 2017 at 12:48 AM, Florian Fainelli [off-list ref] wrote:

quoted

On 06/21/2017 02:59 PM, Rafael J. Wysocki wrote:

quoted

On Wed, Jun 21, 2017 at 11:16 PM, Florian Fainelli [off-list ref] wrote:

quoted

On 06/09/2017 03:53 PM, Rafael J. Wysocki wrote:

[cut]

For the reasons explained before, if the same set of drivers need to
deal with one or more platform_suspend_ops driver, say a classic
homegrown one, and one that is ACPI/ARM SCPI based for instance, we
would have to sprinkle checks like these in the driver:

static int drv_suspend(struct device *d)
{
        if (platform_suspend_get_state() == PM_SUSPEND_STANDBY ||
            acpi_target_system_state() == XXXX |


and so on and so forth, that does not seem to scale horizontally.

quoted

ACPI has acpi_target_system_state() for this very purpose, for example.

quoted

If this seems acceptable to you along with proper documentation to
illustrate the platform specific meaning of these states, I will got
ahead and cook a patch.

I wouldn't like platform-specific things to pretend that they are generic.

Would a notifier model be more appropriate perhaps? The mechanism by
which the notifications get registered to and signaled can be made
generic, the exact information however would be inherently
platform_suspend_ops specific, and only the relevant drivers that need
to subscribe to that kind of information would do that.

Please see the message I've just sent in this thread. :-)

Thanks,
Rafael