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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
