Re: [PATCH 3/4] PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization

[Rafael J. Wysocki]

On Tue, Dec 19, 2017 at 2:15 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> On 19 December 2017 at 12:19, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>> On Tue, Dec 19, 2017 at 12:13 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>>> On Tue, Dec 19, 2017 at 8:38 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>>>> On 10 December 2017 at 01:00, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
>>>>> From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
>>>>>
>>
>> [cut]
>>
>>>
>>>> Moreover, what happens when/if a driver that has deployed this
>>>> solution, starts being used on a new SoC and then additional
>>>> operations during system suspend becomes required (for example
>>>> pinctrls that needs to be put in a system sleep state)? Then
>>>> everything falls apart, doesn't it?
>>>
>>> Then you runtime-resume the device in ->suspend() and the remaining
>>> callbacks will run for you just fine.
>>
>> BTW, I guess you'll need a middle layer in that case anyway so that
>> the driver doesn't have to distinguish between platforms it has to
>> work with which makes the argument somewhat moot.
>
> No, this isn't the case. Let's take the pinctrl as an example.
>
> The pinctrl system sleep state could be optionally defined in the DT,
> depending on the platform.
>
> All the driver shall do, is to try to set the state, if it has been defined.

And how exactly does the driver know what state should be set during
system suspend, say?

Anyway, though, as I said, nothing forces you to set
DPM_FLAG_SMART_SUSPEND.  Don't set it if it is not suitable for you
and no one else is going to be affected.

Thanks,
Rafael