Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support

[Tomasz Figa]

On Tue, Oct 3, 2017 at 11:23 PM, sakari.ailus@xxxxxx
<sakari.ailus@xxxxxx> wrote:
> On Wed, Sep 20, 2017 at 11:45:20AM +0300, sakari.ailus@xxxxxx wrote:
>> > >> @@ -743,11 +770,17 @@ static int at24_probe(struct i2c_client *client, const
>> > >> struct i2c_device_id *id)
>> > >>
>> > >>       i2c_set_clientdata(client, at24);
>> > >>
>> > >> +     /* enable runtime pm */
>> > >> +     pm_runtime_get_noresume(&client->dev);
>> > >> +     pm_runtime_set_active(&client->dev);
>> > >> +     pm_runtime_enable(&client->dev);
>> >
>> > Do we need this get_noresume/set_active dance? I remember it was for
>> > some reason needed for PCI devices, but I don't see why for I2C
>> > anything else than just pm_runtime_enable() would be necessary.
>>
>> You specifically do not need (all) this for PCI devices, but AFAIU for Iæ
>> devices you do. The runtime PM status of a device is disabled by default
>> and the use count is zero, but on ACPI based systems the device is still
>> powered on.
>>
>> >
>> > Also, we enable runtime PM, but we don't provide any callbacks. If
>> > there is no callback in any level of the hierarchy, NULL would be
>> > returned in [3], making [2] return -ENOSYS and [1] fail. The behavior
>> > depends on subsystem and whether the device is attached to a
>> > pm_domain. In our particular case I'd guess the device would be in an
>> > ACPI pm_domain and that would work, but the driver is generic and must
>> > work in any cases.
>>
>> Agreed.
>
> I looked at the code and what actually happens here is the runtime_suspend
> and runtime_resume callbacks aren't set is that the first pm_runtime_put()
> call itself succeeds because checking the the runtime_suspend callback will
> be done in the work queue function. This leaves the device in RPM_ACTIVE
> state, which I don't think is a problem since the driver did not have
> explicit functions to control the device power state.
>
> Further pm_runtime_put() and pm_runtime_get() calls will succeed because
> the device is in RPM_ACTIVE state.
>
> So I see no reason to set the callbacks if they would not actually control
> regulators, clocks or GPIOs required by the device.
>
> Cc linux-pm.

Sounds reasonable. I remember seeing some problems in the past, but
looks like they may be already fixed in current upstream. Thanks for
checking this thoroughly.

Best regards,
Tomasz