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: <CAPDyKFoMcAo889jcfb6nGFUVabsvTDme3yWkW+f0xtfRWPtaxQ@mail.gmail.com>
Date: Wed, 28 Jan 2026 11:25:44 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: "Kevin Hilman (TI)" <khilman@...libre.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org, 
	Dhruva Gole <d-gole@...com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] PM / QoS: add flag to indicate latency applies system-wide

On Wed, 21 Jan 2026 at 02:54, Kevin Hilman (TI) <khilman@...libre.com> wrote:
>
> By default, the QoS resume latency currenly only applied to runtime PM
> decisions.
>
> Add new PM_QOS_FLAG_LATENCY_SYS flag to indicate that the
> resume latency QoS constraint should be applied to system-wide
> PM, and *not* runtime PM.

What if we need latency constraints to be applied for both runtime PM
and system-wide PM? Can that be done?

>
> Signed-off-by: Kevin Hilman (TI) <khilman@...libre.com>
> ---
>  drivers/base/power/sysfs.c | 27 +++++++++++++++++++++++++++
>  include/linux/pm_qos.h     |  2 ++
>  2 files changed, 29 insertions(+)
>
> diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> index 13b31a3adc77..9136c13c17e4 100644
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -316,6 +316,32 @@ static ssize_t pm_qos_no_power_off_store(struct device *dev,
>
>  static DEVICE_ATTR_RW(pm_qos_no_power_off);
>
> +static ssize_t pm_qos_latency_sys_show(struct device *dev,
> +                                      struct device_attribute *attr,
> +                                      char *buf)
> +{
> +       return sysfs_emit(buf, "%d\n", !!(dev_pm_qos_requested_flags(dev)
> +                                         & PM_QOS_FLAG_LATENCY_SYS));
> +}
> +
> +static ssize_t pm_qos_latency_sys_store(struct device *dev,
> +                                        struct device_attribute *attr,
> +                                        const char *buf, size_t n)
> +{
> +       int ret;
> +
> +       if (kstrtoint(buf, 0, &ret))
> +               return -EINVAL;
> +
> +       if (ret != 0 && ret != 1)
> +               return -EINVAL;
> +
> +       ret = dev_pm_qos_update_flags(dev, PM_QOS_FLAG_LATENCY_SYS, ret);
> +       return ret < 0 ? ret : n;
> +}
> +
> +static DEVICE_ATTR_RW(pm_qos_latency_sys);

Shouldn't this code be moved below, inside the #ifdef CONFIG_PM_SLEEP?

I also wonder if "pm_qos_latency_sys" may be slightly too short to
allow the user to understand what it's used for. Perhaps we should
rename it to something along the lines of
"pm_qos_latency_wakeup_enabled". Just a thought, no strong opinions.

> +
>  #ifdef CONFIG_PM_SLEEP
>  static const char _enabled[] = "enabled";
>  static const char _disabled[] = "disabled";
> @@ -681,6 +707,7 @@ static const struct attribute_group pm_qos_latency_tolerance_attr_group = {
>
>  static struct attribute *pm_qos_flags_attrs[] = {
>         &dev_attr_pm_qos_no_power_off.attr,
> +       &dev_attr_pm_qos_latency_sys.attr,
>         NULL,
>  };
>  static const struct attribute_group pm_qos_flags_attr_group = {
> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> index 6cea4455f867..aededda52b6b 100644
> --- a/include/linux/pm_qos.h
> +++ b/include/linux/pm_qos.h
> @@ -37,6 +37,8 @@ enum pm_qos_flags_status {
>  #define PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT (-1)
>
>  #define PM_QOS_FLAG_NO_POWER_OFF       (1 << 0)
> +/* latency value applies to system-wide suspend/s2idle */
> +#define PM_QOS_FLAG_LATENCY_SYS                (2 << 0)
>
>  enum pm_qos_type {
>         PM_QOS_UNITIALIZED,
>
> --
> 2.51.0
>

What about documentation?

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ