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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 3 Oct 2017 17:23:50 +0300
From:   "sakari.ailus@....fi" <sakari.ailus@....fi>
To:     Tomasz Figa <tfiga@...omium.org>
Cc:     "Mani, Rajmohan" <rajmohan.mani@...el.com>,
        "Mohandass, Divagar" <divagar.mohandass@...el.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "wsa@...-dreams.de" <wsa@...-dreams.de>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        mika.westerberg@...ux.intel.com, linux-pm@...r.kernel.org
Subject: Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support

On Wed, Sep 20, 2017 at 11:45:20AM +0300, sakari.ailus@....fi 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²C
> 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.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@....fi