Drivers taking different actions depending on sleep state

[Rafael J. Wysocki]

On Thu, Jun 22, 2017 at 5:18 PM, Florian Fainelli <f.fainelli at gmail.com> wrote:
>
>
> On 06/21/2017 05:03 PM, Rafael J. Wysocki wrote:
>> On Thu, Jun 22, 2017 at 1:55 AM, Florian Fainelli <f.fainelli at gmail.com> wrote:
>>> On 06/21/2017 03:57 PM, Rafael J. Wysocki wrote:
>>>> On Thu, Jun 22, 2017 at 12:48 AM, Florian Fainelli <f.fainelli at gmail.com> wrote:
>>>>> On 06/21/2017 02:59 PM, Rafael J. Wysocki wrote:
>>>>>> On Wed, Jun 21, 2017 at 11:16 PM, Florian Fainelli <f.fainelli at gmail.com> wrote:
>>>>>>> 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.
>
>>
>> ACPI has acpi_target_system_state() for this very purpose, for example.
>>
>>> 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