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]
Message-ID: <CAAFQd5AQX+OuxkkXsyBXO3v-Fyv49kOK9Gdpcp1+XgZLm0KMHQ@mail.gmail.com>
Date:   Tue, 26 Sep 2017 14:33:37 +0900
From:   Tomasz Figa <tfiga@...omium.org>
To:     "Mohandass, Divagar" <divagar.mohandass@...el.com>
Cc:     "sakari.ailus@....fi" <sakari.ailus@....fi>,
        "Mani, Rajmohan" <rajmohan.mani@...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" <mika.westerberg@...ux.intel.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support

[+Rafael, Ulf]

On Tue, Sep 26, 2017 at 2:29 PM, Mohandass, Divagar
<divagar.mohandass@...el.com> wrote:
> Hi Sakari & Tomas,
>
> Are you ok with the current revision, let me know if any changes are needed.

Nope, my concerns have not been addressed, but we need someone from
the PM world to clarify how we should do this to work on all
platforms.

Best regards,
Tomasz

P.S. Please avoid top-posting on mailing lists, it is considered bad manner.

>
> ---
> ^Divagar
>
>>-----Original Message-----
>>From: sakari.ailus@....fi [mailto:sakari.ailus@....fi]
>>Sent: Wednesday, September 20, 2017 3:02 PM
>>To: Tomasz Figa <tfiga@...omium.org>
>>Cc: Mani, Rajmohan <rajmohan.mani@...el.com>; Mohandass, Divagar
>><divagar.mohandass@...el.com>; robh+dt@...nel.org;
>>mark.rutland@....com; wsa@...-dreams.de; devicetree@...r.kernel.org;
>>linux-i2c@...r.kernel.org; linux-kernel@...r.kernel.org;
>>mika.westerberg@...ux.intel.com
>>Subject: Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support
>>
>>Hi Tomasz,
>>
>>On Wed, Sep 20, 2017 at 05:59:18PM +0900, Tomasz Figa wrote:
>>> On Wed, Sep 20, 2017 at 5:45 PM, sakari.ailus@....fi
>>> <sakari.ailus@....fi> wrote:
>>> > Hi Tomasz,
>>> >
>>> > On Wed, Sep 20, 2017 at 12:56:09PM +0900, Tomasz Figa wrote:
>>> >> Thanks Raj.
>>> >>
>>> >> Let me post my comments inline.
>>> >>
>>> >> On Wed, Sep 20, 2017 at 12:52 PM, Mani, Rajmohan
>>> >> <rajmohan.mani@...el.com> wrote:
>>> >> > Adding Tomasz...
>>> >> >
>>> >> >> -----Original Message-----
>>> >> >> From: Mohandass, Divagar
>>> >> >> Sent: Monday, September 04, 2017 3:29 AM
>>> >> >> To: robh+dt@...nel.org; mark.rutland@....com; wsa@...-
>>dreams.de;
>>> >> >> sakari.ailus@....fi
>>> >> >> Cc: devicetree@...r.kernel.org; linux-i2c@...r.kernel.org;
>>> >> >> linux- kernel@...r.kernel.org; Mani, Rajmohan
>>> >> >> <rajmohan.mani@...el.com>; Mohandass, Divagar
>>> >> >> <divagar.mohandass@...el.com>
>>> >> >> Subject: [PATCH v6 3/3] eeprom: at24: enable runtime pm support
>>> >> >>
>>> >> >> Currently the device is kept in D0, there is an opportunity to
>>> >> >> save power by enabling runtime pm.
>>> >> >>
>>> >> >> Device can be daisy chained from PMIC and we can't rely on I2C
>>> >> >> core for auto resume/suspend. Driver will decide when to
>>resume/suspend.
>>> >> >>
>>> >> >> Signed-off-by: Divagar Mohandass <divagar.mohandass@...el.com>
>>> >> >> ---
>>> >> >>  drivers/misc/eeprom/at24.c | 38
>>> >> >> ++++++++++++++++++++++++++++++++++++++
>>> >> >>  1 file changed, 38 insertions(+)
>>> >> >>
>>> >> >> diff --git a/drivers/misc/eeprom/at24.c
>>> >> >> b/drivers/misc/eeprom/at24.c index 2199c42..d718a7a 100644
>>> >> >> --- a/drivers/misc/eeprom/at24.c
>>> >> >> +++ b/drivers/misc/eeprom/at24.c
>>> >> >> @@ -24,6 +24,7 @@
>>> >> >>  #include <linux/i2c.h>
>>> >> >>  #include <linux/nvmem-provider.h>  #include
>>> >> >> <linux/platform_data/at24.h>
>>> >> >> +#include <linux/pm_runtime.h>
>>> >> >>
>>> >> >>  /*
>>> >> >>   * I2C EEPROMs from most vendors are inexpensive and mostly
>>> >> >> interchangeable.
>>> >> >> @@ -501,11 +502,21 @@ static ssize_t
>>> >> >> at24_eeprom_write_i2c(struct at24_data *at24, const char *buf,
>>> >> >> static int at24_read(void *priv, unsigned int off, void *val, size_t
>>count)  {
>>> >> >>       struct at24_data *at24 = priv;
>>> >> >> +     struct i2c_client *client;
>>> >> >>       char *buf = val;
>>> >> >> +     int ret;
>>> >> >>
>>> >> >>       if (unlikely(!count))
>>> >> >>               return count;
>>> >> >>
>>> >> >> +     client = at24_translate_offset(at24, &off);
>>> >> >> +
>>> >> >> +     ret = pm_runtime_get_sync(&client->dev);
>>> >> >> +     if (ret < 0) {
>>> >> >> +             pm_runtime_put_noidle(&client->dev);
>>> >> >> +             return ret;
>>> >> >> +     }
>>> >> >> +
>>> >> >>       /*
>>> >> >>        * Read data from chip, protecting against concurrent updates
>>> >> >>        * from this host, but not from other I2C masters.
>>> >> >> @@ -518,6 +529,7 @@ static int at24_read(void *priv, unsigned
>>> >> >> int off, void *val, size_t count)
>>> >> >>               status = at24->read_func(at24, buf, off, count);
>>> >> >>               if (status < 0) {
>>> >> >>                       mutex_unlock(&at24->lock);
>>> >> >> +                     pm_runtime_put(&client->dev);
>>> >> >>                       return status;
>>> >> >>               }
>>> >> >>               buf += status;
>>> >> >> @@ -527,17 +539,29 @@ static int at24_read(void *priv, unsigned
>>> >> >> int off, void *val, size_t count)
>>> >> >>
>>> >> >>       mutex_unlock(&at24->lock);
>>> >> >>
>>> >> >> +     pm_runtime_put(&client->dev);
>>> >> >> +
>>> >> >>       return 0;
>>> >> >>  }
>>> >> >>
>>> >> >>  static int at24_write(void *priv, unsigned int off, void *val, size_t
>>count)  {
>>> >> >>       struct at24_data *at24 = priv;
>>> >> >> +     struct i2c_client *client;
>>> >> >>       char *buf = val;
>>> >> >> +     int ret;
>>> >> >>
>>> >> >>       if (unlikely(!count))
>>> >> >>               return -EINVAL;
>>> >> >>
>>> >> >> +     client = at24_translate_offset(at24, &off);
>>> >> >> +
>>> >> >> +     ret = pm_runtime_get_sync(&client->dev);
>>> >> >> +     if (ret < 0) {
>>> >> >> +             pm_runtime_put_noidle(&client->dev);
>>> >> >> +             return ret;
>>> >> >> +     }
>>> >> >> +
>>> >> >>       /*
>>> >> >>        * Write data to chip, protecting against concurrent updates
>>> >> >>        * from this host, but not from other I2C masters.
>>> >> >> @@ -550,6 +574,7 @@ static int at24_write(void *priv, unsigned
>>> >> >> int off, void *val, size_t count)
>>> >> >>               status = at24->write_func(at24, buf, off, count);
>>> >> >>               if (status < 0) {
>>> >> >>                       mutex_unlock(&at24->lock);
>>> >> >> +                     pm_runtime_put(&client->dev);
>>> >> >>                       return status;
>>> >> >>               }
>>> >> >>               buf += status;
>>> >> >> @@ -559,6 +584,8 @@ static int at24_write(void *priv, unsigned
>>> >> >> int off, void *val, size_t count)
>>> >> >>
>>> >> >>       mutex_unlock(&at24->lock);
>>> >> >>
>>> >> >> +     pm_runtime_put(&client->dev);
>>> >> >> +
>>> >> >>       return 0;
>>> >> >>  }
>>> >> >>
>>> >> >> @@ -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.
>>>
>>> Okay, so _get_noresume() and _set_active() would do the thing for ACPI
>>> indeed, but not sure about other platforms. Perhaps _enable(),
>>> _get_sync() would be more general?
>>
>>What I ended up doing in e.g. the smiapp driver was to explicitly power the
>>device on first and then enable runtime PM. (See
>>drivers/media/i2c/smiapp/smiapp-core.c .) This approach works even if
>>CONFIG_PM is disabled, both on DT and ACPI.
>>
>>--
>>Regards,
>>
>>Sakari Ailus
>>e-mail: sakari.ailus@....fi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ