* [PATCH v8 1/5] cpufreq/amd-pstate: Add dynamic energy performance preference
From: Mario Limonciello (AMD) @ 2026-04-02 5:02 UTC (permalink / raw)
To: Gautham R . Shenoy
Cc: Perry Yuan, open list:X86 ARCHITECTURE (32-BIT AND 64-BIT),
open list:CPU FREQUENCY SCALING FRAMEWORK,
Mario Limonciello (AMD)
In-Reply-To: <20260402050214.1238624-1-superm1@kernel.org>
Dynamic energy performance preference changes the EPP profile based on
whether the machine is running on AC or DC power.
A notification chain from the power supply core is used to adjust EPP
values on plug in or plug out events.
When enabled, the driver exposes a sysfs toggle for dynamic EPP, blocks
manual writes to energy_performance_preference, and keeps the policy in
performance mode while it "owns" the EPP updates.
For non-server systems:
* the default EPP for AC mode is `performance`.
* the default EPP for DC mode is `balance_performance`.
For server systems dynamic EPP is mostly a no-op.
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
---
v7->v8:
* Handle failures to enable dynamic epp
* Don't set policy to CPUFREQ_POLICY_PERFORMANCE in dymamic epp
* Allow policy governor changes
v6->v7:
* Fix accidental casualty of floor perf from rebase (Gautham)
* Adjust documentation (Gautham)
---
Documentation/admin-guide/pm/amd-pstate.rst | 18 ++-
drivers/cpufreq/Kconfig.x86 | 12 ++
drivers/cpufreq/amd-pstate.c | 128 +++++++++++++++++++-
drivers/cpufreq/amd-pstate.h | 10 +-
4 files changed, 160 insertions(+), 8 deletions(-)
diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst
index b43675b7f739b..bb1341763882b 100644
--- a/Documentation/admin-guide/pm/amd-pstate.rst
+++ b/Documentation/admin-guide/pm/amd-pstate.rst
@@ -325,7 +325,7 @@ and user can change current preference according to energy or performance needs
Please get all support profiles list from
``energy_performance_available_preferences`` attribute, all the profiles are
integer values defined between 0 to 255 when EPP feature is enabled by platform
-firmware, if EPP feature is disabled, driver will ignore the written value
+firmware, but if the dynamic EPP feature is enabled, driver will block writes.
This attribute is read-write.
``boost``
@@ -347,6 +347,22 @@ boost or `1` to enable it, for the respective CPU using the sysfs path
Other performance and frequency values can be read back from
``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`.
+Dynamic energy performance profile
+==================================
+The amd-pstate driver supports dynamically selecting the energy performance
+profile based on whether the machine is running on AC or DC power.
+
+Whether this behavior is enabled by default depends on the kernel
+config option `CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP`. This behavior can also be overridden
+at runtime by the sysfs file ``/sys/devices/system/cpu/cpufreq/policyX/dynamic_epp``.
+
+When set to enabled, the driver will select a different energy performance
+profile when the machine is running on battery or AC power.
+When set to disabled, the driver will not change the energy performance profile
+based on the power source and will not react to user desired power state.
+
+Attempting to manually write to the ``energy_performance_preference`` sysfs
+file will fail when ``dynamic_epp`` is enabled.
``amd-pstate`` vs ``acpi-cpufreq``
======================================
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index 2c5c228408bf2..cdaa8d858045a 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -68,6 +68,18 @@ config X86_AMD_PSTATE_DEFAULT_MODE
For details, take a look at:
<file:Documentation/admin-guide/pm/amd-pstate.rst>.
+config X86_AMD_PSTATE_DYNAMIC_EPP
+ bool "AMD Processor P-State dynamic EPP support"
+ depends on X86_AMD_PSTATE
+ default n
+ help
+ Allow the kernel to dynamically change the energy performance
+ value from events like ACPI platform profile and AC adapter plug
+ events.
+
+ This feature can also be changed at runtime, this configuration
+ option only sets the kernel default value behavior.
+
config X86_AMD_PSTATE_UT
tristate "selftest for AMD Processor P-State driver"
depends on X86 && ACPI_PROCESSOR
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index f207252eb5f5f..379e7dd442522 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -36,6 +36,7 @@
#include <linux/io.h>
#include <linux/delay.h>
#include <linux/uaccess.h>
+#include <linux/power_supply.h>
#include <linux/static_call.h>
#include <linux/topology.h>
@@ -86,6 +87,11 @@ static struct cpufreq_driver amd_pstate_driver;
static struct cpufreq_driver amd_pstate_epp_driver;
static int cppc_state = AMD_PSTATE_UNDEFINED;
static bool amd_pstate_prefcore = true;
+#ifdef CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP
+static bool dynamic_epp = CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP;
+#else
+static bool dynamic_epp;
+#endif
static struct quirk_entry *quirks;
/*
@@ -1155,6 +1161,73 @@ static void amd_pstate_cpu_exit(struct cpufreq_policy *policy)
kfree(cpudata);
}
+static int amd_pstate_get_balanced_epp(struct cpufreq_policy *policy)
+{
+ struct amd_cpudata *cpudata = policy->driver_data;
+
+ if (power_supply_is_system_supplied())
+ return cpudata->epp_default_ac;
+ else
+ return cpudata->epp_default_dc;
+}
+
+static int amd_pstate_power_supply_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct amd_cpudata *cpudata = container_of(nb, struct amd_cpudata, power_nb);
+ struct cpufreq_policy *policy __free(put_cpufreq_policy) = cpufreq_cpu_get(cpudata->cpu);
+ u8 epp;
+ int ret;
+
+ if (event != PSY_EVENT_PROP_CHANGED)
+ return NOTIFY_OK;
+
+ epp = amd_pstate_get_balanced_epp(policy);
+
+ ret = amd_pstate_set_epp(policy, epp);
+ if (ret)
+ pr_warn("Failed to set CPU %d EPP %u: %d\n", cpudata->cpu, epp, ret);
+
+ return NOTIFY_OK;
+}
+static void amd_pstate_clear_dynamic_epp(struct cpufreq_policy *policy)
+{
+ struct amd_cpudata *cpudata = policy->driver_data;
+
+ if (cpudata->power_nb.notifier_call)
+ power_supply_unreg_notifier(&cpudata->power_nb);
+ cpudata->dynamic_epp = false;
+}
+
+static int amd_pstate_set_dynamic_epp(struct cpufreq_policy *policy)
+{
+ struct amd_cpudata *cpudata = policy->driver_data;
+ int ret;
+ u8 epp;
+
+ epp = amd_pstate_get_balanced_epp(policy);
+ ret = amd_pstate_set_epp(policy, epp);
+ if (ret)
+ return ret;
+
+ /* only enable notifier if things will actually change */
+ if (cpudata->epp_default_ac != cpudata->epp_default_dc) {
+ cpudata->power_nb.notifier_call = amd_pstate_power_supply_notifier;
+ ret = power_supply_reg_notifier(&cpudata->power_nb);
+ if (ret)
+ goto cleanup;
+ }
+
+ cpudata->dynamic_epp = true;
+
+ return 0;
+
+cleanup:
+ amd_pstate_clear_dynamic_epp(policy);
+
+ return ret;
+}
+
/* Sysfs attributes */
/*
@@ -1244,14 +1317,19 @@ static ssize_t store_energy_performance_preference(
ssize_t ret;
u8 epp;
+ if (cpudata->dynamic_epp) {
+ pr_debug("EPP cannot be set when dynamic EPP is enabled\n");
+ return -EBUSY;
+ }
+
ret = sysfs_match_string(energy_perf_strings, buf);
if (ret < 0)
return -EINVAL;
- if (!ret)
- epp = cpudata->epp_default;
- else
+ if (ret)
epp = epp_values[ret];
+ else
+ epp = amd_pstate_get_balanced_epp(policy);
if (epp > 0 && policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
pr_debug("EPP cannot be set under performance policy\n");
@@ -1259,6 +1337,8 @@ static ssize_t store_energy_performance_preference(
}
ret = amd_pstate_set_epp(policy, epp);
+ if (ret)
+ return ret;
return ret ? ret : count;
}
@@ -1620,12 +1700,42 @@ static ssize_t prefcore_show(struct device *dev,
return sysfs_emit(buf, "%s\n", str_enabled_disabled(amd_pstate_prefcore));
}
+static ssize_t dynamic_epp_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sysfs_emit(buf, "%s\n", str_enabled_disabled(dynamic_epp));
+}
+
+static ssize_t dynamic_epp_store(struct device *a, struct device_attribute *b,
+ const char *buf, size_t count)
+{
+ bool enabled;
+ int ret;
+
+ ret = kstrtobool(buf, &enabled);
+ if (ret)
+ return ret;
+
+ if (dynamic_epp == enabled)
+ return -EINVAL;
+
+ /* reinitialize with desired dynamic EPP value */
+ dynamic_epp = enabled;
+ ret = amd_pstate_change_driver_mode(cppc_state);
+ if (ret)
+ dynamic_epp = false;
+
+ return ret ? ret : count;
+}
+
static DEVICE_ATTR_RW(status);
static DEVICE_ATTR_RO(prefcore);
+static DEVICE_ATTR_RW(dynamic_epp);
static struct attribute *pstate_global_attributes[] = {
&dev_attr_status.attr,
&dev_attr_prefcore.attr,
+ &dev_attr_dynamic_epp.attr,
NULL
};
@@ -1715,13 +1825,17 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
if (amd_pstate_acpi_pm_profile_server() ||
amd_pstate_acpi_pm_profile_undefined()) {
policy->policy = CPUFREQ_POLICY_PERFORMANCE;
- cpudata->epp_default = amd_pstate_get_epp(cpudata);
+ cpudata->epp_default_ac = cpudata->epp_default_dc = amd_pstate_get_epp(cpudata);
} else {
policy->policy = CPUFREQ_POLICY_POWERSAVE;
- cpudata->epp_default = AMD_CPPC_EPP_BALANCE_PERFORMANCE;
+ cpudata->epp_default_ac = AMD_CPPC_EPP_PERFORMANCE;
+ cpudata->epp_default_dc = AMD_CPPC_EPP_BALANCE_PERFORMANCE;
}
- ret = amd_pstate_set_epp(policy, cpudata->epp_default);
+ if (dynamic_epp)
+ ret = amd_pstate_set_dynamic_epp(policy);
+ else
+ ret = amd_pstate_set_epp(policy, amd_pstate_get_balanced_epp(policy));
if (ret)
goto free_cpudata1;
@@ -1753,6 +1867,8 @@ static void amd_pstate_epp_cpu_exit(struct cpufreq_policy *policy)
amd_pstate_update_perf(policy, perf.bios_min_perf, 0U, 0U, 0U, false);
amd_pstate_set_floor_perf(policy, cpudata->bios_floor_perf);
+ if (cpudata->dynamic_epp)
+ amd_pstate_clear_dynamic_epp(policy);
kfree(cpudata);
policy->driver_data = NULL;
}
diff --git a/drivers/cpufreq/amd-pstate.h b/drivers/cpufreq/amd-pstate.h
index 32b8b26ce388f..d929ae3163b3d 100644
--- a/drivers/cpufreq/amd-pstate.h
+++ b/drivers/cpufreq/amd-pstate.h
@@ -85,6 +85,11 @@ struct amd_aperf_mperf {
* AMD P-State driver supports preferred core featue.
* @epp_cached: Cached CPPC energy-performance preference value
* @policy: Cpufreq policy value
+ * @suspended: If CPU core if offlined
+ * @epp_default_ac: Default EPP value for AC power source
+ * @epp_default_dc: Default EPP value for DC power source
+ * @dynamic_epp: Whether dynamic EPP is enabled
+ * @power_nb: Notifier block for power events
*
* The amd_cpudata is key private data for each CPU thread in AMD P-State, and
* represents all the attributes and goals that AMD P-State requests at runtime.
@@ -118,7 +123,10 @@ struct amd_cpudata {
/* EPP feature related attributes*/
u32 policy;
bool suspended;
- u8 epp_default;
+ u8 epp_default_ac;
+ u8 epp_default_dc;
+ bool dynamic_epp;
+ struct notifier_block power_nb;
};
/*
--
2.43.0
^ permalink raw reply related
* [PATCH v8 0/5] amd-pstate Dynamic EPP and raw EPP
From: Mario Limonciello (AMD) @ 2026-04-02 5:02 UTC (permalink / raw)
To: Gautham R . Shenoy
Cc: Perry Yuan, open list:X86 ARCHITECTURE (32-BIT AND 64-BIT),
open list:CPU FREQUENCY SCALING FRAMEWORK,
Mario Limonciello (AMD)
Dynamic EPP allows the kernel to register amd-pstate as part of
a platform profile. It will change EPP modes matching the user's
preference to the platform profile sysfs files as well as power
adapter state.
Raw EPP allows userspace to write integers to
energy_performance_preference.
This is based off superm1/linux-next.
Mario Limonciello (AMD) (5):
cpufreq/amd-pstate: Add dynamic energy performance preference
cpufreq/amd-pstate: add kernel command line to override dynamic epp
cpufreq/amd-pstate: Add support for platform profile class
cpufreq/amd-pstate: Add support for raw EPP writes
cpufreq/amd-pstate-ut: Add a unit test for raw EPP
.../admin-guide/kernel-parameters.txt | 7 +
Documentation/admin-guide/pm/amd-pstate.rst | 41 ++-
drivers/cpufreq/Kconfig.x86 | 13 +
drivers/cpufreq/amd-pstate-ut.c | 109 +++++++
drivers/cpufreq/amd-pstate.c | 281 ++++++++++++++++--
drivers/cpufreq/amd-pstate.h | 21 +-
6 files changed, 449 insertions(+), 23 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Fenglin Wu @ 2026-04-02 4:45 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio, Subbaraman Narayanamurthy,
linux-arm-msm, devicetree, linux-kernel, linux-pm, kernel
In-Reply-To: <ht2vvduvxvz3s36cn5m54hv3zon7qelrgat3tnykfvqi7f56fd@t24kmaliap5l>
On 4/1/2026 7:31 PM, Dmitry Baryshkov wrote:
> On Wed, Apr 01, 2026 at 02:15:31AM -0700, Fenglin Wu wrote:
>> Add the RPMh power domains required for the Hawi SoC. This includes
>> new definitions for domains supplying specific hardware components:
>> - DCX: supplies VDD_DISP
>> - GBX: supplies VDD_GFX_BX
>>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>> ---
>> drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 38 insertions(+)
>>
>> + [RPMHPD_LCX] = &lcx,
>> + [RPMHPD_LMX] = &lmx,
>> + [RPMHPD_MMCX] = &mmcx,
>> + [RPMHPD_MMCX_AO] = &mmcx_ao,
> So, should it be just mmcx or mmcx_w_cx_parent ?
It is mmcx.
There is no such requirement to vote cx before voting mmcx on Hawi SoC.
>> + [RPMHPD_MX] = &mx,
>> + [RPMHPD_MX_AO] = &mx_ao,
^ permalink raw reply
* Re: [PATCH v3 0/2] Support BPF traversal of wakeup sources
From: Greg Kroah-Hartman @ 2026-04-02 4:06 UTC (permalink / raw)
To: Samuel Wu
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Danilo Krummrich,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, kernel-team,
linux-kernel, linux-pm, driver-core, bpf, linux-kselftest
In-Reply-To: <CAG2KctokEVVuhrs6tYuMjFF4ALR=tX80iZHrt4bhVvEKyoHzRQ@mail.gmail.com>
On Wed, Apr 01, 2026 at 12:07:12PM -0700, Samuel Wu wrote:
> On Wed, Apr 1, 2026 at 2:15 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Mar 31, 2026 at 08:34:09AM -0700, Samuel Wu wrote:
> > > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > > wakeup_sources, and puts a config flag around the sysfs interface.
> > >
> > > Currently, a traversal of wakeup sources require going through
> > > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > > wakeup source also having multiple attributes. debugfs is unstable and
> > > insecure.
> >
> > Describe "inefficient" please?
>
> Ack; I’ll provide a more detailed breakdown in the v4 cover letter. To
> summarize: the "inefficiency" isn't just the number of sources (150),
> but the fact that each source has 10 attributes. We are looking at
> 1,500+ sysfs nodes to get a full snapshot of the system.
Wait, no, something is wrong here. You should NEVER be wanting to
combine multiple sysfs files at the same time into a "snapshot" of the
system because by virtue of how this works, it's going to change while
you are actually traversing all of those files!
Why are you trying to read 1500+ sysfs files at once, and what are you
doing with that information? And if you really need it "all at once",
why can't we provide it for you in a sane manner, instead of being
forced to either walk the whole sysfs tree, or rely on a bpf script?
So, what problem are you trying to solve that looking at all of these
files solves for you at the moment?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 4/4] PM / devfreq: Optimize error return value of governor_show()
From: Jie Zhan @ 2026-04-02 3:38 UTC (permalink / raw)
To: Yaxiong Tian, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <20260401033128.67925-1-tianyaxiong@kylinos.cn>
On 4/1/2026 11:31 AM, Yaxiong Tian wrote:
> When df->governor is NULL, governor_show() returns -EINVAL, which
> confuses users.
>
> To fix this issue, return -ENOENT to indicate that no governor is
> currently set for the device.
>
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> drivers/devfreq/devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 975f82d7a9d1..c40568d2a4dc 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1377,7 +1377,7 @@ static ssize_t governor_show(struct device *dev,
> struct devfreq *df = to_devfreq(dev);
>
> if (!df->governor)
> - return -EINVAL;
> + return -ENOENT;
Hi Yaxiong,
Usually we don't change sysfs error code because that might break userspace
if it depends on this to do some specific handling (although it shouldn't
do so!)
Besides that, from a user-friendliness point of view, I'd still prefer
ENODEV.
A user terminal is supposed to get "No such file" on -ENOENT and "No such
device" on -ENODEV.
I guess the latter is more meaningful since 'device' can mean 'object'?
"No such file" is a bit confusing because the sysfs file or entry is
clearly there.
Thanks,
Jie
>
> return sprintf(buf, "%s\n", df->governor->name);
> }
^ permalink raw reply
* Re: [PATCH v2 3/4] PM / devfreq: Fix governor_store() failing when device has no current governor
From: Jie Zhan @ 2026-04-02 3:21 UTC (permalink / raw)
To: Yaxiong Tian, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <20260401033119.67821-1-tianyaxiong@kylinos.cn>
On 4/1/2026 11:31 AM, Yaxiong Tian wrote:
> Since devfreq_remove_governor() may clear the device's current governor
> in certain situations, while governors actually exist independently
> of the device, directly returning EINVAL in this case is inaccurate.
>
> To fix this issue, remove this check and add relevant logic for when
> df->governor is NULL.
>
> Fixes: 483d557ee9a3 ("PM / devfreq: Clean up the devfreq instance name in sysfs attr")
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> drivers/devfreq/devfreq.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 2977b07be939..975f82d7a9d1 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1390,9 +1390,6 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
> char str_governor[DEVFREQ_NAME_LEN + 1];
> const struct devfreq_governor *governor, *prev_governor;
>
> - if (!df->governor)
> - return -EINVAL;
> -
> ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
> if (ret != 1)
> return -EINVAL;
> @@ -1403,6 +1400,20 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
> ret = PTR_ERR(governor);
> goto out;
> }
> +
> + if (!df->governor) {
> + df->governor = governor;
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> + if (ret) {
> + dev_warn(dev, "%s: Governor %s not started(%d)\n",
> + __func__, df->governor->name, ret);
> + df->governor = NULL;
> + } else {
> + ret = sysfs_update_group(&df->dev.kobj, &gov_attr_group);
> + }
> + goto out;
> + }
> +
> if (df->governor == governor) {
> ret = 0;
> goto out;
Hi Yaxiong,
I'd suggest something like this, such that the main body of the function is
not changed.
Note that this is just an example. Not tested or carefully checked.
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 2977b07be939..aa0f1db3225c 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1390,9 +1390,6 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
char str_governor[DEVFREQ_NAME_LEN + 1];
const struct devfreq_governor *governor, *prev_governor;
- if (!df->governor)
- return -EINVAL;
-
ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
if (ret != 1)
return -EINVAL;
@@ -1403,6 +1400,10 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
ret = PTR_ERR(governor);
goto out;
}
+
+ if (!df->governor)
+ goto skip_stop;
+
if (df->governor == governor) {
ret = 0;
goto out;
@@ -1423,6 +1424,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
goto out;
}
+skip_stop:
/*
* Start the new governor and create the specific sysfs files
* which depend on the new governor.
@@ -1435,6 +1437,8 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
__func__, df->governor->name, ret);
/* Restore previous governor */
+ if (!prev_governor)
+ goto out;
df->governor = prev_governor;
ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
if (ret) {
^ permalink raw reply related
* Re: [PATCH v2 2/4] PM / devfreq: Fix available_governors_show() when no governor is set
From: Jie Zhan @ 2026-04-02 3:10 UTC (permalink / raw)
To: Yaxiong Tian
Cc: linux-pm, linux-kernel, MyungJoo Ham, Kyungmin Park,
최찬우, nm
In-Reply-To: <20260401033055.67608-1-tianyaxiong@kylinos.cn>
On 4/1/2026 11:30 AM, Yaxiong Tian wrote:
> Since devfreq_remove_governor() may clear the device's current governor
> in certain situations, while governors actually exist independently of
> the device, directly returning EINVAL in this case is inaccurate.
>
> To fix this issue, remove this check and use df->governor for validity
> verification in the following code.
>
> Fixes: 483d557ee9a3 ("PM / devfreq: Clean up the devfreq instance name in sysfs attr")
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
Well, you should have picked up my RB.
https://lore.kernel.org/all/baee47c8-7b29-42dd-a64a-167c19c4593b@hisilicon.com/
Some tools like b4 may make that easier.
[...]
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: clock: qcom,milos-camcc: Document interconnect path
From: Mike Tipton @ 2026-04-02 3:10 UTC (permalink / raw)
To: Luca Weiss
Cc: Konrad Dybcio, Krzysztof Kozlowski, Taniya Das, Georgi Djakov,
Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, ~postmarketos/upstreaming,
phone-devel, linux-pm, linux-kernel, linux-arm-msm, linux-clk,
devicetree
In-Reply-To: <DHG7CMLREKDF.2L5V5VQCEYDKH@fairphone.com>
Hi Luca,
On Mon, Mar 30, 2026 at 04:55:40PM +0200, Luca Weiss wrote:
> Hi Mike,
>
> On Tue Mar 24, 2026 at 3:48 AM CET, Mike Tipton wrote:
> > On Mon, Jan 19, 2026 at 11:28:07AM +0100, Konrad Dybcio wrote:
> >>
> >>
> >> On 1/19/26 11:20 AM, Konrad Dybcio wrote:
> >> > On 1/17/26 12:46 PM, Krzysztof Kozlowski wrote:
> >> >> On Fri, Jan 16, 2026 at 02:17:21PM +0100, Luca Weiss wrote:
> >> >>> Document an interconnect path for camcc that's required to enable
> >> >>> the CAMSS_TOP_GDSC power domain.
> >> >>
> >> >> I find it confusing. Enabling GDSC power domains is done via power
> >> >> domains, not via interconnects. Do not represent power domains as
> >> >> interconnects, it's something completely different.
> >> >
> >> > The name of the power domains is CAMSS_TOP_GDSC (seems you misread)
> >> >
> >> > For the power domain to successfully turn on, the MNoC needs to be
> >> > turned on (empirical evidence). The way to do it is to request a
> >> > nonzero vote on this interconnect path
> >> >
> >> > (presumably because the GDSC or its invisible providers require
> >> > something connected over that bus to carry out their enable sequences).
> >
> > The GDSC itself shouldn't depend on MMNOC in order to turn on properly.
> > It should turn on just fine without it. There *is* a dependency between
> > CAM_TOP_GDSC and MMNOC, but it's in the opposite direction.
>
> I can personally just write from practical experience, as Qualcomm
> doesn't share any relevant documentation with OEMs.
>
> Without this patch the GDSC refuses to turn on.
>
> [ 291.055839] ------------[ cut here ]------------
> [ 291.055860] cam_cc_camss_top_gdsc status stuck at 'off'
> [ 291.055878] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x138/0x144, CPU#4: hexdump/1995
>
> With the patch it turns on just fine, no issues seen.
I haven't observed that behavior, and I just reconfirmed on a more
recent chip. I explicitly toggled this GDSC on/off while MMNOC is
collapsed and it turns on fine. And if I disable MMNOC while the GDSC is
still on, then MMNOC gets stuck entering collapse. But I haven't tried
on Milos, specifically. It's possible there's some behavior unique to it
that I'm not aware of.
Regardless, the correct solution for both issues (MMNOC getting stuck
turning off or the GDSC getting stuck turning on) is the same. Which is
to vote for MMNOC on behalf of the GDSC as your patch does. And is also
what we've done downstream.
>
> As Konrad has written, originally I didn't see any issue because that
> interconnect was being kept alive by simple-framebuffer where I've added
> 'interconnects' to keep the framebuffer alive. However when testing
> without this, the GDSC would refuse to turn on, which led me to this
> patch series.
>
> Additionally you can see in downstream devicetree you can also see an
> interconnect defined for the "cam_cc_camss_top_gdsc" node:
>
> https://gerrit-public.fairphone.software/plugins/gitiles/platform/vendor/qcom/proprietary/devicetree/+/refs/heads/odm/rc/target/15/fp6/fps_overlay/volcano.dtsi#2943
Right, this logic was originally added to prevent MMNOC from getting
stuck in collapse, rather than to prevent the GDSC from getting stuck
turning on.
Mike
>
> Regards
> Luca
^ permalink raw reply
* Re: [PATCH v2 1/4] PM / devfreq: Fix possible null pointer issue in devfreq_add_governor()
From: Jie Zhan @ 2026-04-02 3:06 UTC (permalink / raw)
To: Yaxiong Tian, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <20260401033046.67482-1-tianyaxiong@kylinos.cn>
On 4/1/2026 11:30 AM, Yaxiong Tian wrote:
> When a user removes a governor using devfreq_remove_governor(), if
> the current device is using this governor, devfreq->governor will
> be set to NULL. When the user registers any governor
> using devfreq_add_governor(), since devfreq->governor is NULL, a
> null pointer error occurs in strncmp().
>
> For example: A user loads the userspace gov through a module, then
> a device selects userspace. When unloading the userspace module and
> then loading it again, the null pointer error occurs:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000000000000010
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> *******************skip *********************
> Call trace:
> __pi_strncmp+0x20/0x1b8
> devfreq_userspace_init+0x1c/0xff8 [governor_userspace]
> do_one_initcall+0x4c/0x278
> do_init_module+0x5c/0x218
> load_module+0x1f1c/0x1fc8
> init_module_from_file+0x8c/0xd0
> __arm64_sys_finit_module+0x220/0x3d8
> invoke_syscall+0x48/0x110
> el0_svc_common.constprop.0+0xbc/0xe8
> do_el0_svc+0x20/0x30
> el0_svc+0x24/0xb8
> el0t_64_sync_handler+0xb8/0xc0
> el0t_64_sync+0x14c/0x150
>
> To fix this issue, remove the list_for_each_entry() logic, as
> find_devfreq_governor() has already checked for the existence of
> governor with the same name. This makes it impossible to find a
> duplicate governor in the list, so the subsequent logic is
> unreachable and can be removed.
>
> Fixes: 1b5c1be2c88e ("PM / devfreq: map devfreq drivers to governor using name")
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> drivers/devfreq/devfreq.c | 33 ---------------------------------
> 1 file changed, 33 deletions(-)
>
> Hi Jie Zhan:
> If you're willing, I'd like to add your Co-developed-by tag.
Yeah please do so. That would be:
Co-developed-by: Jie Zhan <zhanjie9@hisilicon.com>
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
The rest looks good to me.
^ permalink raw reply
* [PATCH] pmdomain: qcom: cpr: add COMPILE_TEST support
From: Rosen Penev @ 2026-04-02 2:54 UTC (permalink / raw)
To: linux-pm; +Cc: Ulf Hansson, open list:ARM/QUALCOMM MAILING LIST, open list
Allows the buildbots to build the driver on other platforms. There's
nothing special arch specific thing going on here.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/pmdomain/qcom/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pmdomain/qcom/Kconfig b/drivers/pmdomain/qcom/Kconfig
index 3d3948eabef0..72cbcfe7a0c9 100644
--- a/drivers/pmdomain/qcom/Kconfig
+++ b/drivers/pmdomain/qcom/Kconfig
@@ -3,7 +3,7 @@ menu "Qualcomm PM Domains"
config QCOM_CPR
tristate "QCOM Core Power Reduction (CPR) support"
- depends on ARCH_QCOM && HAS_IOMEM
+ depends on (ARCH_QCOM || COMPILE_TEST) && HAS_IOMEM
select PM_OPP
select REGMAP
help
--
2.53.0
^ permalink raw reply related
* [PATCH RESEND v1] thermal: core: fix blocking in unregistering zone
From: Jiajia Liu @ 2026-04-02 2:27 UTC (permalink / raw)
To: Rafael J . Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
linux-pm, linux-kernel
Cc: Jiajia Liu
When hwmon->tz_list has more than one member,
thermal_remove_hwmon_sysfs does not unregister hwmon->device.
Unregistering the zone which is parent of hwmon->device blocks
at wait_for_completion(&tz->removal). Add check and move hwmon
to other zone in thermal_remove_hwmon_sysfs.
One method of reproducing hung task is to unbind the first
acpitz zone on systems with two acpitz zones.
$ cd /sys/bus/platform/drivers/acpi-thermal/
$ ls
bind LNXTHERM:00 LNXTHERM:01 uevent unbind
$ echo 'LNXTHERM:00' | sudo tee unbind > /dev/null
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
---
drivers/thermal/thermal_hwmon.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index b624892bc6d6..43cde079fef0 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -242,6 +242,15 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz)
list_del(&temp->hwmon_node);
kfree(temp);
if (!list_empty(&hwmon->tz_list)) {
+ if (hwmon->device->parent == &tz->device) {
+ struct thermal_hwmon_temp *first;
+
+ first = list_first_entry(&hwmon->tz_list,
+ struct thermal_hwmon_temp,
+ hwmon_node);
+ device_move(hwmon->device, &first->tz->device,
+ DPM_ORDER_DEV_AFTER_PARENT);
+ }
mutex_unlock(&thermal_hwmon_list_lock);
return;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v1] thermal: core: fix blocking in unregistering zone
From: Jiajia Liu @ 2026-04-02 2:18 UTC (permalink / raw)
To: Rafael J . Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
linux-pm, linux-kernel
Cc: Jiajia Liu
From: Jiajia Liu <liujiajia@kylinos.cn>
When hwmon->tz_list has more than one member,
thermal_remove_hwmon_sysfs does not unregister hwmon->device.
Unregistering the zone which is parent of hwmon->device blocks
at wait_for_completion(&tz->removal). Add check and move hwmon
to other zone in thermal_remove_hwmon_sysfs.
One method of reproducing hung task is to unbind the first
acpitz zone on systems with two acpitz zones.
$ cd /sys/bus/platform/drivers/acpi-thermal/
$ ls
bind LNXTHERM:00 LNXTHERM:01 uevent unbind
$ echo 'LNXTHERM:00' | sudo tee unbind > /dev/null
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
---
drivers/thermal/thermal_hwmon.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index b624892bc6d6..43cde079fef0 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -242,6 +242,15 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz)
list_del(&temp->hwmon_node);
kfree(temp);
if (!list_empty(&hwmon->tz_list)) {
+ if (hwmon->device->parent == &tz->device) {
+ struct thermal_hwmon_temp *first;
+
+ first = list_first_entry(&hwmon->tz_list,
+ struct thermal_hwmon_temp,
+ hwmon_node);
+ device_move(hwmon->device, &first->tz->device,
+ DPM_ORDER_DEV_AFTER_PARENT);
+ }
mutex_unlock(&thermal_hwmon_list_lock);
return;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v10 5/6] power: supply: max77759: add charger driver
From: Amit Sunil Dhamne @ 2026-04-02 1:25 UTC (permalink / raw)
To: Sebastian Reichel
Cc: André Draszik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, linux-kernel, devicetree, linux-usb,
linux-pm, linux-arm-kernel, linux-samsung-soc, RD Babiera,
Kyle Tso
In-Reply-To: <ac2jYUA2F5oQsA2g@venus>
Hi Sebastian,
Thanks for the review!
On 4/1/26 4:17 PM, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Mar 31, 2026 at 11:22:20PM +0000, Amit Sunil Dhamne via B4 Relay wrote:
>> +/* Charge Termination Voltage Limits (in mV) */
>> +static const struct linear_range chg_cv_prm_ranges[] = {
>> + LINEAR_RANGE(3800, 0x38, 0x39, 100),
>> + LINEAR_RANGE(4000, 0x0, 0x32, 10),
>> +};
> Let me quote from include/linux/power_supply.h:
>
> * All voltages, currents, charges, energies, time and temperatures in uV,
> * µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
> * stated. It's driver's job to convert its raw values to units in which
> * this class operates.
>
> What makes you think that CONSTANT_CHARGE_VOLTAGE_MAX is
> special?
>
> [...]
It was an oversight, I will fix it.
>
>> +static int max77759_charger_get_property(struct power_supply *psy,
>> + enum power_supply_property psp,
>> + union power_supply_propval *pval)
>> +{
>> + struct max77759_charger *chg = power_supply_get_drvdata(psy);
>> + int ret;
>> +
>> + switch (psp) {
>> + case POWER_SUPPLY_PROP_ONLINE:
>> + ret = get_online(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_PRESENT:
>> + ret = charger_input_valid(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_STATUS:
>> + ret = get_status(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_CHARGE_TYPE:
>> + ret = get_charge_type(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_HEALTH:
>> + ret = get_health(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
>> + ret = get_fast_charge_current(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
>> + ret = get_float_voltage(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
>> + ret = get_input_current_limit(chg);
>> + break;
>> + default:
>> + ret = -EINVAL;
>> + }
>> +
>> + pval->intval = ret;
>> + return ret < 0 ? ret : 0;
> As people like to use existing drivers as reference this definitely
> needs a comment, that none of the properties used by this driver
> support negative values. This is not a general thing as e.g. the
> CHARGE current may be negative depending on the battery being
> charged or discharged (OTG mode).
Ah okay, thanks for letting me know. I will add a comment.
As these patches are already in flight and part of usb-next of the usb
tree, I can send the suggested improvements as a separate patch, if that
works for you and Greg.
BR,
Amit
>
> Greetings,
>
> -- Sebastian
^ permalink raw reply
* Re: [PATCH RESEND 0/5] bitmap: cleanup bitmaps printing
From: Yury Norov @ 2026-04-02 0:57 UTC (permalink / raw)
To: linux-kernel, Christophe Leroy (CS GROUP), Peter Zijlstra (Intel),
Rafael J. Wysocki, Alexander Shishkin, Daniel Lezcano,
Ingo Molnar, James Clark, Kees Cook, Lukasz Luba,
Madhavan Srinivasan, Michael Ellerman, Mike Leach, Moritz Fischer,
Nicholas Piggin, Russ Weight, Shrikanth Hegde, Suki K Poulose,
Tom Rix, Thomas Weißschuh, Xu Yilun, Yury Norov, Zhang Rui,
coresight, linux-arm-kernel, linux-fpga, linux-pm, linuxppc-dev
Cc: Jakub Kicinski
In-Reply-To: <abxaIMi55N4X9JWz@yury>
On Thu, Mar 19, 2026 at 04:18:40PM -0400, Yury Norov wrote:
> Ping?
OK, taking 1-4 in bitmap-for-next.
Thanks,
Yury
> On Tue, Mar 03, 2026 at 03:08:36PM -0500, Yury Norov wrote:
> > Bitmap API has a bitmap_print_to_pagebuf() function that is intended to
> > print bitmap into a human readable format, making sure that the output
> > string will not get big enough to cross the current page limit.
> >
> > Some drivers use this function immediately before passing the result to
> > scnprintf() with no modification. This is useless because scnprintf(),
> > and helpers based on it like seq_pritf() and sysfs_emit(), take care of
> > not overflowing the buffer by itself, and perfectly print bitmaps with
> > "%*pb[l]".
> >
> > This is a resend of non-networking part of [1]. Patches #3,5 switch from
> > plain scnprintf() to sysfs_emit(), as pointed out by Thomas Weißschuh.
> >
> > [1] https://lore.kernel.org/all/20260219181407.290201-1-ynorov@nvidia.com/
> >
> > The networking part, for reference:
> >
> > https://lore.kernel.org/all/20260303185507.111841-1-ynorov@nvidia.com/
> >
> > Each patch can be applied individually per corresponding subsystem.
> >
> > Yury Norov (5):
> > powerpc/xive: simplify xive_spapr_debug_show()
> > thermal: intel: switch cpumask_get() to using
> > cpumask_print_to_pagebuf()
> > coresight: don't use bitmap_print_to_pagebuf()
> > lib/prime_numbers: drop temporary buffer in dump_primes()
> > fpga: m10bmc-sec: switch show_canceled_csk() to using sysfs_emit()
> >
> > arch/powerpc/sysdev/xive/spapr.c | 12 ++-----
> > drivers/fpga/intel-m10-bmc-sec-update.c | 3 +-
> > .../hwtracing/coresight/coresight-cti-sysfs.c | 32 ++++++++-----------
> > drivers/thermal/intel/intel_powerclamp.c | 3 +-
> > lib/math/tests/prime_numbers_kunit.c | 6 ++--
> > 5 files changed, 21 insertions(+), 35 deletions(-)
> >
> > --
> > 2.43.0
^ permalink raw reply
* Re: [PATCH v10 5/6] power: supply: max77759: add charger driver
From: Sebastian Reichel @ 2026-04-01 23:17 UTC (permalink / raw)
To: amitsd
Cc: André Draszik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, linux-kernel, devicetree, linux-usb,
linux-pm, linux-arm-kernel, linux-samsung-soc, RD Babiera,
Kyle Tso
In-Reply-To: <20260331-max77759-charger-v10-5-76f59233c369@google.com>
[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]
Hi,
On Tue, Mar 31, 2026 at 11:22:20PM +0000, Amit Sunil Dhamne via B4 Relay wrote:
> +/* Charge Termination Voltage Limits (in mV) */
> +static const struct linear_range chg_cv_prm_ranges[] = {
> + LINEAR_RANGE(3800, 0x38, 0x39, 100),
> + LINEAR_RANGE(4000, 0x0, 0x32, 10),
> +};
Let me quote from include/linux/power_supply.h:
* All voltages, currents, charges, energies, time and temperatures in uV,
* µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
* stated. It's driver's job to convert its raw values to units in which
* this class operates.
What makes you think that CONSTANT_CHARGE_VOLTAGE_MAX is
special?
[...]
> +static int max77759_charger_get_property(struct power_supply *psy,
> + enum power_supply_property psp,
> + union power_supply_propval *pval)
> +{
> + struct max77759_charger *chg = power_supply_get_drvdata(psy);
> + int ret;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_ONLINE:
> + ret = get_online(chg);
> + break;
> + case POWER_SUPPLY_PROP_PRESENT:
> + ret = charger_input_valid(chg);
> + break;
> + case POWER_SUPPLY_PROP_STATUS:
> + ret = get_status(chg);
> + break;
> + case POWER_SUPPLY_PROP_CHARGE_TYPE:
> + ret = get_charge_type(chg);
> + break;
> + case POWER_SUPPLY_PROP_HEALTH:
> + ret = get_health(chg);
> + break;
> + case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
> + ret = get_fast_charge_current(chg);
> + break;
> + case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
> + ret = get_float_voltage(chg);
> + break;
> + case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
> + ret = get_input_current_limit(chg);
> + break;
> + default:
> + ret = -EINVAL;
> + }
> +
> + pval->intval = ret;
> + return ret < 0 ? ret : 0;
As people like to use existing drivers as reference this definitely
needs a comment, that none of the properties used by this driver
support negative values. This is not a general thing as e.g. the
CHARGE current may be negative depending on the battery being
charged or discharged (OTG mode).
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 04/12] arm64: support WFET in smp_cond_load_relaxed_timeout()
From: Ankur Arora @ 2026-04-01 22:31 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ankur Arora, linux-kernel, linux-arch, linux-arm-kernel, linux-pm,
bpf, arnd, will, peterz, akpm, mark.rutland, harisokn, cl, ast,
rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai, rdunlap,
david.laight.linux, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <acz3D1SkqDqyH0Dy@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> On Sun, Mar 15, 2026 at 06:36:43PM -0700, Ankur Arora wrote:
>> To handle WFET use __cmpwait_timeout() similarly to __cmpwait(). These
>> call out to the respective __cmpwait_case_timeout_##sz(),
>> __cmpwait_case_##sz() functions.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Great. Thanks Catalin.
--
ankur
^ permalink raw reply
* [PATCH] power: supply: bd71828: add input current limit property
From: Andreas Kemnade @ 2026-04-01 21:17 UTC (permalink / raw)
To: Matti Vaittinen, Sebastian Reichel
Cc: linux-pm, linux-kernel, Andreas Kemnade
Add input current property to be able to work around issues created by
automatic input limiting and have some control.
Disabling the automatic management is another step.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
drivers/power/supply/bd71828-power.c | 62 ++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/drivers/power/supply/bd71828-power.c b/drivers/power/supply/bd71828-power.c
index 0e00acb589937..5e78faa0a4aaf 100644
--- a/drivers/power/supply/bd71828-power.c
+++ b/drivers/power/supply/bd71828-power.c
@@ -24,6 +24,7 @@
#define BD7182x_MASK_CONF_PON BIT(0)
#define BD71815_MASK_CONF_XSTB BIT(1)
#define BD7182x_MASK_BAT_STAT 0x3f
+#define BD7182x_MASK_ILIM 0x3f
#define BD7182x_MASK_DCIN_STAT 0x07
#define BD7182x_MASK_WDT_AUTO 0x40
@@ -48,9 +49,11 @@ struct pwr_regs {
unsigned int vbat_avg;
unsigned int ibat;
unsigned int ibat_avg;
+ unsigned int ilim_stat;
unsigned int btemp_vth;
unsigned int chg_state;
unsigned int bat_temp;
+ unsigned int dcin_set;
unsigned int dcin_stat;
unsigned int dcin_online_mask;
unsigned int dcin_collapse_limit;
@@ -66,9 +69,11 @@ static const struct pwr_regs pwr_regs_bd71828 = {
.vbat_avg = BD71828_REG_VBAT_U,
.ibat = BD71828_REG_IBAT_U,
.ibat_avg = BD71828_REG_IBAT_AVG_U,
+ .ilim_stat = BD71828_REG_ILIM_STAT,
.btemp_vth = BD71828_REG_VM_BTMP_U,
.chg_state = BD71828_REG_CHG_STATE,
.bat_temp = BD71828_REG_BAT_TEMP,
+ .dcin_set = BD71828_REG_DCIN_SET,
.dcin_stat = BD71828_REG_DCIN_STAT,
.dcin_online_mask = BD7182x_MASK_DCIN_DET,
.dcin_collapse_limit = BD71828_REG_DCIN_CLPS,
@@ -441,6 +446,7 @@ static int bd71828_charger_get_property(struct power_supply *psy,
struct bd71828_power *pwr = dev_get_drvdata(psy->dev.parent);
u32 vot;
u16 tmp;
+ int t;
int online;
int ret;
@@ -459,6 +465,20 @@ static int bd71828_charger_get_property(struct power_supply *psy,
vot = tmp;
/* 5 milli volt steps */
val->intval = 5000 * vot;
+ break;
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ if (!pwr->regs->ilim_stat)
+ return -ENODATA;
+
+ ret = regmap_read(pwr->regmap, pwr->regs->ilim_stat, &t);
+ if (ret)
+ return ret;
+
+ t++;
+ val->intval = (t & BD7182x_MASK_ILIM) * 50000;
+ if (val->intval > 2000000)
+ val->intval = 2000000;
+
break;
default:
return -EINVAL;
@@ -467,6 +487,45 @@ static int bd71828_charger_get_property(struct power_supply *psy,
return 0;
}
+static int bd71828_charger_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct bd71828_power *pwr = dev_get_drvdata(psy->dev.parent);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ if (val->intval > 2000000)
+ return -EINVAL;
+
+ if (val->intval < 50000)
+ return -EINVAL;
+
+ if (!pwr->regs->dcin_set)
+ return -EINVAL;
+
+ return regmap_update_bits(pwr->regmap, pwr->regs->dcin_set,
+ BD7182x_MASK_ILIM,
+ val->intval / 50000 - 1);
+ break;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int bd71828_charger_property_is_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ struct bd71828_power *pwr = dev_get_drvdata(psy->dev.parent);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ return !!(pwr->regs->dcin_set);
+ default:
+ return false;
+ }
+}
+
static int bd71828_battery_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
@@ -571,6 +630,7 @@ static int bd71828_battery_property_is_writeable(struct power_supply *psy,
/** @brief ac properties */
static const enum power_supply_property bd71828_charger_props[] = {
+ POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
@@ -600,6 +660,8 @@ static const struct power_supply_desc bd71828_ac_desc = {
.properties = bd71828_charger_props,
.num_properties = ARRAY_SIZE(bd71828_charger_props),
.get_property = bd71828_charger_get_property,
+ .set_property = bd71828_charger_set_property,
+ .property_is_writeable = bd71828_charger_property_is_writeable,
};
static const struct power_supply_desc bd71828_bat_desc = {
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20260401-bd-inp-limit-3acb51e15e9c
Best regards,
--
Andreas Kemnade <andreas@kemnade.info>
^ permalink raw reply related
* Re: [PATCH v1] thermal: core: Fix thermal zone device registration error path
From: Lukasz Luba @ 2026-04-01 21:02 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Daniel Lezcano, LKML, Linux PM
In-Reply-To: <2849815.mvXUDI8C0e@rafael.j.wysocki>
Hi Rafael,
On 4/1/26 15:33, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> If thermal_zone_device_register_with_trips() fails after registering
> a thermal zone device, it needs to wait for the tz->removal completion
> like thermal_zone_device_unregister(), in case user space has managed
> to take a reference to the thermal zone device's kobject, in which case
> thermal_release() may not be called by the error path itself and tz may
> be freed prematurely.
>
> Add the missing wait_for_completion() call to the thermal zone device
> registration error path.
>
> Fixes: 04e6ccfc93c5 ("thermal: core: Fix NULL pointer dereference in zone registration error path")
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: All applicable <stable@vger.kernel.org>
> ---
> drivers/thermal/thermal_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1651,6 +1651,7 @@ unregister:
> device_del(&tz->device);
> release_device:
> put_device(&tz->device);
> + wait_for_completion(&tz->removal);
> remove_id:
> ida_free(&thermal_tz_ida, id);
> free_tzp:
>
>
>
LGTM. I have also tested that code path with a faked
failure from device_register() - the mechanism works.
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: Lukasz Luba <lukasz.luba@arm.com>
Regards,
Lukasz
^ permalink raw reply
* [PATCH] power: sequencing: pcie-m2: add SERIAL_DEV_BUS dependency
From: Arnd Bergmann @ 2026-04-01 19:10 UTC (permalink / raw)
To: Bartosz Golaszewski, Manivannan Sadhasivam
Cc: Arnd Bergmann, Ulf Hansson, Michal Wilczynski, linux-pm,
linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The newly added serdev code fails to link when serdev is turned off:
arm-linux-gnueabi-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_pcie_m2_remove_serdev':
pwrseq-pcie-m2.c:(.text+0xc8): undefined reference to `serdev_device_remove'
arm-linux-gnueabi-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_m2_pcie_notify':
pwrseq-pcie-m2.c:(.text+0x69c): undefined reference to `of_find_serdev_controller_by_node'
arm-linux-gnueabi-ld: pwrseq-pcie-m2.c:(.text+0x6f8): undefined reference to `serdev_device_alloc'
arm-linux-gnueabi-ld: pwrseq-pcie-m2.c:(.text+0x724): undefined reference to `serdev_device_add'
Add another Kconfig dependency for this
Fixes: 3f736aecbdc8 ("power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I noticed this one only after I had already sent the patch to add the other
two dependency, feel free to combine the patches into one
---
drivers/power/sequencing/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
index 77c6d9227251..1c5f5820f5b7 100644
--- a/drivers/power/sequencing/Kconfig
+++ b/drivers/power/sequencing/Kconfig
@@ -39,6 +39,7 @@ config POWER_SEQUENCING_PCIE_M2
tristate "PCIe M.2 connector power sequencing driver"
depends on OF
depends on PCI
+ depends on SERIAL_DEV_BUS
select OF_DYNAMIC
help
Say Y here to enable the power sequencing driver for PCIe M.2
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v3 0/2] Support BPF traversal of wakeup sources
From: Samuel Wu @ 2026-04-01 19:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Danilo Krummrich,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, kernel-team,
linux-kernel, linux-pm, driver-core, bpf, linux-kselftest
In-Reply-To: <2026040136-ocelot-simply-8981@gregkh>
On Wed, Apr 1, 2026 at 2:15 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Mar 31, 2026 at 08:34:09AM -0700, Samuel Wu wrote:
> > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > wakeup_sources, and puts a config flag around the sysfs interface.
> >
> > Currently, a traversal of wakeup sources require going through
> > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > wakeup source also having multiple attributes. debugfs is unstable and
> > insecure.
>
> Describe "inefficient" please?
Ack; I’ll provide a more detailed breakdown in the v4 cover letter. To
summarize: the "inefficiency" isn't just the number of sources (150),
but the fact that each source has 10 attributes. We are looking at
1,500+ sysfs nodes to get a full snapshot of the system.
>
> And if you really think that doing an open/read/close on a virtual
> filesystem is inefficient, then I have the syscall for you!
>
> I've been trying to get readfile() accepted every few years, looks like
> I last tried in 2020:
> https://lore.kernel.org/r/20200704140250.423345-1-gregkh@linuxfoundation.org
> but I keep the patchset up to date in my local tree all the time.
>
> Would that help you out here instead?
`readfile()` seems like it would be a great optimization for many
usecases, but it doesn't solve the context switch bottleneck.
Additionally, current userspace implementations attempt to speed up
this traversal by caching fds, so this new syscall wouldn't help as
much as one might initially expect.
> > Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> > traverse the wakeup sources list. The head address of wakeup_sources can
> > safely be resolved through BPF helper functions or variable attributes.
>
> Who is going to be calling this?
BPF programs call the new kfuncs. I realized I left some stale text in
the v2 cover letter regarding the interface; I'll clean that up for
the next version to make this point clearer.
> > On a quiescent Pixel 6 traversing 150 wakeup_sources, I am seeing ~34x
> > speedup (sampled 75 times in table below). For a device under load, the
> > speedup is greater.
> > +-------+----+----------+----------+
> > | | n | AVG (ms) | STD (ms) |
> > +-------+----+----------+----------+
> > | sysfs | 75 | 44.9 | 12.6 |
> > +-------+----+----------+----------+
> > | BPF | 75 | 1.3 | 0.7 |
> > +-------+----+----------+----------+
>
> 150 sysfs calls in 44.9 ms feels very slow. but really, what are you
> expecting here, sysfs should NEVER be on a "fast path" that you care
> about performance. Why are you hammering on sysfs here? What HAS to
> have this type of performance?
>
> In other words, what problem are you trying to solve that having access
> to 150+ sysfs files all at once in a faster way is going to fix?
The 44.9ms is the cost of reading ~1,500 sysfs nodes (150 sources * 10
attributes). This is even worse on wearables, where the compute and
power constrained platform exacerbates performance sensitivity even
more.
On these platforms, the CPU is suspended as much as possible. A
byproduct of this is that the wakeup source traversal occurs on a
user-perceptible path, which impacts battery life and UI
responsiveness.
Beyond the performance improvement, moving to BPF offers other benefits:
1. Reduce Memory: Drop the fd caching logic
2. Simplify Security: Consolidate SELinux permissions rather than
managing labels for every single *possible* wakeup_source
Thanks Greg!
-- Sam
^ permalink raw reply
* Re: [PATCH] cpupower: remove extern declarations in cmd_set()
From: Shuah Khan @ 2026-04-01 18:53 UTC (permalink / raw)
To: Kumar, Kaushlendra, shuah@kernel.org, jwyatt@redhat.com,
jkacur@redhat.com
Cc: linux-pm@vger.kernel.org, Shuah Khan
In-Reply-To: <LV3PR11MB87682C0658A16EC72B47FB72F550A@LV3PR11MB8768.namprd11.prod.outlook.com>
On 3/31/26 20:49, Kumar, Kaushlendra wrote:
> On 4/1/26 XX:XX, Shuah Khan wrote:
>> Okay - are there errors from compilers or static checkers? How did you find the problem?
>
> No errors from compilers or static checkers. We found this while doing
> local code modifications to the file. During the review of the changes,
> we noticed the redundant extern declarations and cleaned them up as part
> of good housekeeping.
There are a few other places in cpupower that can be fixed. Send
me a patch that removes just the extern declarations without the
parse_int_range() stuff
extern char *optarg;
extern int optind, opterr, optopt;
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH] PM / wakeup: Allocate class wakeup_class statically
From: Rafael J. Wysocki @ 2026-04-01 17:32 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Greg Kroah-Hartman,
Danilo Krummrich, Linux PM, driver-core
In-Reply-To: <744440a6-e1cb-4792-a848-57755de0686b@gmail.com>
On Wed, Apr 1, 2026 at 5:45 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 01.04.2026 16:19, Rafael J. Wysocki wrote:
> > On Sun, Mar 29, 2026 at 6:14 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>
> >> Allocating wakeup_class statically avoids a little runtime overhead.
> >> Define groups and device release function as part of the class, so that
> >> we don't have to repeat this for each class device.
> >> Whilst at it, constify wakeup_source_attrs[].
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >
> > Can you please have a look at this and let me know what you think:
> >
> > https://sashiko.dev/#/patchset/0fe1b679-ab28-4505-b0db-14e7ac3ba749%40gmail.com
> >
> Interesting finding! I think the diagnosis is right.
>
> But: I would say the current behavior isn't a nice solution as well:
It is not fantastic, but it doesn't have this issue.
> wakeup_source_device_create() does: dev->class = wakeup_class;
> I think no reader will expect that wakeup_class may be NULL here due to
> initcall ordering. In addition this behavior results in such early
> wakeup sources not being shown in sysfs.
They are registered too early to show up in sysfs, but they can work regardless.
I think that it's just pointless to call device_register() for a given
wakeup source if wakeup_class has not been registered yet.
> But I'm not sure whether registering class "wakeup" (and registering
> classes in general) would be possible early enough (core_initcall,
> or even pure_initcall).
driver_init() is called before do_initcalls() is do_basic_setup(), so
class registration should work for all initcall levels AFAICS.
> >> ---
> >> drivers/base/power/wakeup_stats.c | 18 +++++++++---------
> >> 1 file changed, 9 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/base/power/wakeup_stats.c b/drivers/base/power/wakeup_stats.c
> >> index 308f8bde9..72beb8fce 100644
> >> --- a/drivers/base/power/wakeup_stats.c
> >> +++ b/drivers/base/power/wakeup_stats.c
> >> @@ -18,8 +18,6 @@
> >>
> >> #include "power.h"
> >>
> >> -static struct class *wakeup_class;
> >> -
> >> #define wakeup_attr(_name) \
> >> static ssize_t _name##_show(struct device *dev, \
> >> struct device_attribute *attr, char *buf) \
> >> @@ -114,7 +112,7 @@ static ssize_t prevent_suspend_time_ms_show(struct device *dev,
> >> }
> >> static DEVICE_ATTR_RO(prevent_suspend_time_ms);
> >>
> >> -static struct attribute *wakeup_source_attrs[] = {
> >> +static const struct attribute *const wakeup_source_attrs[] = {
> >> &dev_attr_name.attr,
> >> &dev_attr_active_count.attr,
> >> &dev_attr_event_count.attr,
> >> @@ -135,6 +133,12 @@ static void device_create_release(struct device *dev)
> >> kfree(dev);
> >> }
> >>
> >> +static const struct class wakeup_class = {
> >> + .name = "wakeup",
> >> + .dev_release = device_create_release,
> >> + .dev_groups = wakeup_source_groups,
> >> +};
> >> +
> >> static struct device *wakeup_source_device_create(struct device *parent,
> >> struct wakeup_source *ws)
> >> {
> >> @@ -149,10 +153,8 @@ static struct device *wakeup_source_device_create(struct device *parent,
> >>
> >> device_initialize(dev);
> >> dev->devt = MKDEV(0, 0);
> >> - dev->class = wakeup_class;
> >> + dev->class = &wakeup_class;
> >> dev->parent = parent;
> >> - dev->groups = wakeup_source_groups;
> >> - dev->release = device_create_release;
> >> dev_set_drvdata(dev, ws);
> >> device_set_pm_not_required(dev);
> >>
> >> @@ -212,8 +214,6 @@ void wakeup_source_sysfs_remove(struct wakeup_source *ws)
> >>
> >> static int __init wakeup_sources_sysfs_init(void)
> >> {
> >> - wakeup_class = class_create("wakeup");
> >> -
> >> - return PTR_ERR_OR_ZERO(wakeup_class);
> >> + return class_register(&wakeup_class);
> >> }
> >> postcore_initcall(wakeup_sources_sysfs_init);
> >> --
> >> 2.53.0
> >>
>
^ permalink raw reply
* Re: [PATCH V5 0/5] i3c: mipi-i3c-hci-pci: Enable IBI while runtime suspended for Intel controllers
From: Adrian Hunter @ 2026-04-01 17:16 UTC (permalink / raw)
To: alexandre.belloni; +Cc: Frank.Li, rafael, linux-i3c, linux-kernel, linux-pm
In-Reply-To: <20260306085338.62955-1-adrian.hunter@intel.com>
On 06/03/2026 10:53, Adrian Hunter wrote:
> Hi
>
>
> Please note all patches have Frank's Rev'd-by.
Can this be queued for next (v7.1)?
>
>
> Changes in V5:
>
> Re-base on top of v7.0 fixes series:
> https://lore.kernel.org/linux-i3c/20260306072451.11131-1-adrian.hunter@intel.com/T
>
> Changes in V4:
>
> i3c: mipi-i3c-hci: Allow parent to manage runtime PM
> Add Frank's Rev'd-by
>
> i3c: mipi-i3c-hci-pci: Add optional ability to manage child runtime PM
> Add Frank's Rev'd-by
>
>
> Changes in V3:
>
> i3c: master: Mark last_busy on IBI when runtime PM is allowed
> Patch dropped
>
> i3c: mipi-i3c-hci: Add quirk to allow IBI while runtime suspended
> Add Frank's Rev'd-by
>
> i3c: mipi-i3c-hci-pci: Add optional ability to manage child runtime PM
> Remove unnecessary pm_runtime_mark_last_busy()
>
> i3c: mipi-i3c-hci-pci: Enable IBI while runtime suspended for Intel controllers
> Add Frank's Rev'd-by
>
>
> Changes in V2:
>
> i3c: mipi-i3c-hci-pci: Set d3hot_delay to 0 for Intel controllers
> Add Frank's Rev'd-by
>
> i3c: master: Allow controller drivers to select runtime PM device
> Patch dropped
>
> i3c: master: Mark last_busy on IBI when runtime PM is allowed
> Adjusted slightly for earlier changes
>
> i3c: mipi-i3c-hci: Allow parent to manage runtime PM
> For HCI_QUIRK_RPM_PARENT_MANAGED case, change from
> disabling runtime PM to instead causing the runtime PM
> callbacks to do nothing
>
> i3c: mipi-i3c-hci-pci: Add optional ability to manage child runtime PM
> Do not enable autosuspend.
> Callbacks for parent-managed invocation were renamed
> from i3c_hci_runtime_suspend to i3c_hci_rpm_suspend and
> from i3c_hci_runtime_resume to i3c_hci_rpm_resume.
> Amend commit message slightly.
>
> i3c: mipi-i3c-hci-pci: Enable IBI while runtime suspended for Intel controllers
> Retain HCI_QUIRK_RPM_ALLOWED
> Amend commit message accordingly
>
>
> Here are patches related to enabling IBI while runtime suspended for Intel
> controllers.
>
> Intel LPSS I3C controllers can wake from runtime suspend to receive
> in-band interrupts (IBIs).
>
> It is non-trivial to implement because the parent PCI device has 2 I3C bus
> instances (MIPI I3C HCI Multi-Bus Instance capability) represented by
> platform devices with a separate driver, but the IBI-wakeup is shared by
> both, which means runtime PM has to be managed by the parent PCI driver.
>
> To make that work, the PCI driver handles runtime PM, but leverages the
> mipi-i3c-hci platform driver's functionality for saving and restoring
> controller state.
>
>
> Adrian Hunter (5):
> i3c: mipi-i3c-hci-pci: Set d3hot_delay to 0 for Intel controllers
> i3c: mipi-i3c-hci: Add quirk to allow IBI while runtime suspended
> i3c: mipi-i3c-hci: Allow parent to manage runtime PM
> i3c: mipi-i3c-hci-pci: Add optional ability to manage child runtime PM
> i3c: mipi-i3c-hci-pci: Enable IBI while runtime suspended for Intel controllers
>
> drivers/i3c/master/mipi-i3c-hci/core.c | 35 +++++-
> drivers/i3c/master/mipi-i3c-hci/hci.h | 7 ++
> drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c | 135 +++++++++++++++++++++
> 3 files changed, 172 insertions(+), 5 deletions(-)
>
> Regards
> Adrian
^ permalink raw reply
* [PATCH] devfreq: change devfreq_event_class to a const struct
From: Jori Koolstra @ 2026-04-01 16:55 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park
Cc: Jori Koolstra, Greg Kroah-Hartman,
open list:DEVICE FREQUENCY EVENT (DEVFREQ-EVENT), open list
The class_create() call has been deprecated in favor of class_register()
as the driver core now allows for a struct class to be in read-only
memory. Change devfreq_event_class to be a const struct class and drop
the class_create() call. Compile tested.
Link: https://lore.kernel.org/all/2023040244-duffel-pushpin-f738@gregkh/
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
---
drivers/devfreq/devfreq-event.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
index 179de3cf6d6c..9e183cd8818c 100644
--- a/drivers/devfreq/devfreq-event.c
+++ b/drivers/devfreq/devfreq-event.c
@@ -17,7 +17,13 @@
#include <linux/list.h>
#include <linux/of.h>
-static struct class *devfreq_event_class;
+static struct attribute *devfreq_event_attrs[];
+ATTRIBUTE_GROUPS(devfreq_event);
+
+static const struct class devfreq_event_class = {
+ .name = "devfreq-event",
+ .dev_groups = devfreq_event_groups
+};
/* The list of all devfreq event list */
static LIST_HEAD(devfreq_event_list);
@@ -321,7 +327,7 @@ struct devfreq_event_dev *devfreq_event_add_edev(struct device *dev,
edev->desc = desc;
edev->enable_count = 0;
edev->dev.parent = dev;
- edev->dev.class = devfreq_event_class;
+ edev->dev.class = &devfreq_event_class;
edev->dev.release = devfreq_event_release_edev;
dev_set_name(&edev->dev, "event%d", atomic_inc_return(&event_no));
@@ -461,18 +467,15 @@ static struct attribute *devfreq_event_attrs[] = {
&dev_attr_enable_count.attr,
NULL,
};
-ATTRIBUTE_GROUPS(devfreq_event);
static int __init devfreq_event_init(void)
{
- devfreq_event_class = class_create("devfreq-event");
- if (IS_ERR(devfreq_event_class)) {
- pr_err("%s: couldn't create class\n", __FILE__);
- return PTR_ERR(devfreq_event_class);
- }
+ int err;
- devfreq_event_class->dev_groups = devfreq_event_groups;
+ err = class_register(&devfreq_event_class);
+ if (err)
+ pr_err("%s: couldn't create class\n", __FILE__);
- return 0;
+ return err;
}
subsys_initcall(devfreq_event_init);
base-commit: d466c332e106fe666d1e2f5a24d08e308bebbfa1
--
2.53.0
^ permalink raw reply related
* Re: [chanwoo:devfreq-next 5/5] drivers/devfreq/devfreq.c:1946:37: error: redefinition of 'devfreq_group'
From: Jori Koolstra @ 2026-04-01 16:54 UTC (permalink / raw)
To: Chanwoo Choi, kernel test robot, gregkh@linuxfoundation.org
Cc: llvm, oe-kbuild-all, linux-pm, Chanwoo Choi
In-Reply-To: <CAGTfZH0bZMGpdKjvgw7S54NF+KeXPtvhsanKmSs1vHDhx7F7Lg@mail.gmail.com>
> Op 21-03-2026 16:11 CET schreef Chanwoo Choi <chanwoo@kernel.org>:
>
>
> HI Jori,
>
> There are build errors in your patches.
> DId you test it? I hope to fix and test the patch before posting.
>
Yes, I have no built issues. Can it be the test bot did not apply the patch
correctly?
Looking at the build error it seems that ATTRIBUTE_GROUPS(devfreq) is duplicated,
not moved.
>
>
> --
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
Thanks,
Jori.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox