* Re: [PATCH v8 2/2] cpufreq: Add boost_freq_req QoS request
From: Zhongqiu Han @ 2026-03-29 9:00 UTC (permalink / raw)
To: Pierre Gondois, linux-kernel
Cc: Lifeng Zheng, Huang Rui, Gautham R. Shenoy, Mario Limonciello,
Perry Yuan, Rafael J. Wysocki, Viresh Kumar, linux-pm,
zhongqiu.han
In-Reply-To: <20260326204404.1401849-3-pierre.gondois@arm.com>
On 3/27/2026 4:44 AM, Pierre Gondois wrote:
> The Power Management Quality of Service (PM QoS) allows to
> aggregate constraints from multiple entities. It is currently
> used to manage the min/max frequency of a given policy.
>
> Frequency constraints can come for instance from:
> - Thermal framework: acpi_thermal_cpufreq_init()
> - Firmware: _PPC objects: acpi_processor_ppc_init()
> - User: by setting policyX/scaling_[min|max]_freq
> The minimum of the max frequency constraints is used to compute
> the resulting maximum allowed frequency.
>
> When enabling boost frequencies, the same frequency request object
> (policy->max_freq_req) as to handle requests from users is used.
> As a result, when setting:
> - scaling_max_freq
> - boost
> The last sysfs file used overwrites the request from the other
> sysfs file.
>
> To avoid this, create a per-policy boost_freq_req to save the boost
> constraints instead of overwriting the last scaling_max_freq
> constraint.
>
> policy_set_boost() calls the cpufreq set_boost callback.
> Update the newly added boost_freq_req request from there:
> - whenever boost is toggled
> - to cover all possible paths
>
> In the existing .set_boost() callbacks:
> - Don't update policy->max as this is done through the qos notifier
> cpufreq_notifier_max() which calls cpufreq_set_policy().
> - Remove freq_qos_update_request() calls as the qos request is now
> done in policy_set_boost() and updates the new boost_freq_req
>
> $ ## Init state
> scaling_max_freq:1000000
> cpuinfo_max_freq:1000000
>
> $ echo 700000 > scaling_max_freq
> scaling_max_freq:700000
> cpuinfo_max_freq:1000000
>
> $ echo 1 > ../boost
> scaling_max_freq:1200000
> cpuinfo_max_freq:1200000
>
> $ echo 800000 > scaling_max_freq
> scaling_max_freq:800000
> cpuinfo_max_freq:1200000
>
> $ ## Final step:
> $ ## Without the patches:
> $ echo 0 > ../boost
> scaling_max_freq:1000000
> cpuinfo_max_freq:1000000
>
> $ ## With the patches:
> $ echo 0 > ../boost
> scaling_max_freq:800000
> cpuinfo_max_freq:1000000
>
> Note:
> cpufreq_frequency_table_cpuinfo() updates policy->min
> and max from:
> A.
> cpufreq_boost_set_sw()
> \-cpufreq_frequency_table_cpuinfo()
> B.
> cpufreq_policy_online()
> \-cpufreq_table_validate_and_sort()
> \-cpufreq_frequency_table_cpuinfo()
> Keep these updates as some drivers expect policy->min and
> max to be set through B.
>
> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
> drivers/cpufreq/amd-pstate.c | 2 --
> drivers/cpufreq/cppc_cpufreq.c | 10 ++------
> drivers/cpufreq/cpufreq.c | 46 +++++++++++++++++++++++-----------
> include/linux/cpufreq.h | 1 +
> 4 files changed, 34 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 5aa9fcd80cf51..d0675d6a19fe1 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -769,8 +769,6 @@ static int amd_pstate_cpu_boost_update(struct cpufreq_policy *policy, bool on)
> else if (policy->cpuinfo.max_freq > nominal_freq)
> policy->cpuinfo.max_freq = nominal_freq;
>
> - policy->max = policy->cpuinfo.max_freq;
> -
> if (cppc_state == AMD_PSTATE_PASSIVE) {
> ret = freq_qos_update_request(&cpudata->req[1], policy->cpuinfo.max_freq);
> if (ret < 0)
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 011f35cb47b94..f4f574fbe547b 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -807,17 +807,11 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
> {
> struct cppc_cpudata *cpu_data = policy->driver_data;
> struct cppc_perf_caps *caps = &cpu_data->perf_caps;
> - int ret;
>
> if (state)
> - policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
> + policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->highest_perf);
> else
> - policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
> - policy->cpuinfo.max_freq = policy->max;
> -
> - ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> - if (ret < 0)
> - return ret;
> + policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
>
> return 0;
> }
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 5757f12633d16..d2f393d738a39 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -609,10 +609,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
> policy->boost_enabled = enable;
>
> ret = cpufreq_driver->set_boost(policy, enable);
> - if (ret)
> + if (ret) {
> policy->boost_enabled = !policy->boost_enabled;
> + return ret;
> + }
>
> - return ret;
> + ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
> + if (ret < 0) {
> + policy->boost_enabled = !policy->boost_enabled;
> + cpufreq_driver->set_boost(policy, policy->boost_enabled);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static ssize_t store_local_boost(struct cpufreq_policy *policy,
> @@ -1377,6 +1386,7 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
> }
>
> freq_qos_remove_request(policy->min_freq_req);
> + freq_qos_remove_request(policy->boost_freq_req);
> kfree(policy->min_freq_req);
>
> cpufreq_policy_put_kobj(policy);
> @@ -1445,26 +1455,38 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
>
> if (new_policy) {
> + unsigned int count;
> +
> for_each_cpu(j, policy->related_cpus) {
> per_cpu(cpufreq_cpu_data, j) = policy;
> add_cpu_dev_symlink(policy, j, get_cpu_device(j));
> }
>
> - policy->min_freq_req = kzalloc(2 * sizeof(*policy->min_freq_req),
> + count = policy->boost_supported ? 3 : 2;
> + policy->min_freq_req = kzalloc(count * sizeof(*policy->min_freq_req),
> GFP_KERNEL);
> if (!policy->min_freq_req) {
> ret = -ENOMEM;
> goto out_destroy_policy;
> }
>
> + if (policy->boost_supported) {
> + policy->boost_freq_req = policy->min_freq_req + 2;
> +
> + ret = freq_qos_add_request(&policy->constraints,
> + policy->boost_freq_req,
> + FREQ_QOS_MAX,
> + policy->cpuinfo.max_freq);
> + if (ret < 0) {
> + policy->boost_freq_req = NULL;
> + goto out_destroy_policy;
> + }
> + }
> +
> ret = freq_qos_add_request(&policy->constraints,
> policy->min_freq_req, FREQ_QOS_MIN,
> FREQ_QOS_MIN_DEFAULT_VALUE);
> if (ret < 0) {
> - /*
> - * So we don't call freq_qos_remove_request() for an
> - * uninitialized request.
> - */
> kfree(policy->min_freq_req);
> policy->min_freq_req = NULL;
> goto out_destroy_policy;
Hi Pierre, Viresh,
Sorry for the late follow-up on v8. While re-reading the patch, I
noticed a potential UAF issue on an error path — I might be missing
something, so I'd appreciate a double-check.
min_freq_req, max_freq_req and boost_freq_req all point into the same
contiguous kzalloc'd block:
slot0 (min_freq_req + 0) -> min_freq_req
slot1 (min_freq_req + 1) -> max_freq_req
slot2 (min_freq_req + 2) -> boost_freq_req
If boost_freq_req is successfully added to the QoS constraints list, but
the subsequent freq_qos_add_request() for min_freq_req fails, the error
path does:
kfree(policy->min_freq_req); /* frees the entire block, including slot2
*/
policy->min_freq_req = NULL;
goto out_destroy_policy;
policy->boost_freq_req is not set to NULL here, so it becomes a dangling
pointer into freed memory.
cpufreq_policy_free() is then called from cpufreq_online() and does:
freq_qos_remove_request(policy->boost_freq_req); /* UAF */
or this boost qos req will leak.
If freq_qos_add_request() for min_freq_req fails, maybe we can remove
boost qos first, such as:
if (ret < 0) {
if (policy->boost_freq_req) {
freq_qos_remove_request(policy->boost_freq_req);
policy->boost_freq_req = NULL;
}
kfree(policy->min_freq_req);
policy->min_freq_req = NULL;
goto out_destroy_policy;
}
Besides, if freq_qos_add_request() for boost_freq_req fails first on
cpufreq_policy_online(), policy->min_freq_req is valid pointer but qos
req is inactive, will trigger one warn on
freq_qos_remove_request(policy->min_freq_req) {
if (WARN(!freq_qos_request_active(req),
"%s() called for unknown object\n", __func__))
return -EINVAL;
}
> @@ -2788,16 +2810,10 @@ int cpufreq_boost_set_sw(struct cpufreq_policy *policy, int state)
> return -ENXIO;
>
> ret = cpufreq_frequency_table_cpuinfo(policy);
> - if (ret) {
> + if (ret)
> pr_err("%s: Policy frequency update failed\n", __func__);
> - return ret;
> - }
> -
> - ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> - if (ret < 0)
> - return ret;
>
> - return 0;
> + return ret;
> }
> EXPORT_SYMBOL_GPL(cpufreq_boost_set_sw);
>
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index cc894fc389710..89157e367eefa 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -81,6 +81,7 @@ struct cpufreq_policy {
> struct freq_constraints constraints;
> struct freq_qos_request *min_freq_req;
> struct freq_qos_request *max_freq_req;
> + struct freq_qos_request *boost_freq_req;
>
> struct cpufreq_frequency_table *freq_table;
> enum cpufreq_table_sorting freq_table_sorted;
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* [PATCH] PM: EM: Fix null-ptr-deref in get-perf-domains when ID is not found
From: Changwoo Min @ 2026-03-29 7:36 UTC (permalink / raw)
To: lukasz.luba, rafael, lenb, pavel, donald.hunter
Cc: kernel-dev, linux-pm, linux-kernel, Changwoo Min, Yi Lai
dev_energymodel_nl_get_perf_domains_doit() calls
em_perf_domain_get_by_id() but does not check the return value before
passing it to __em_nl_get_pd_size(). When a caller supplies a
non-existent perf domain ID, em_perf_domain_get_by_id() returns NULL,
and __em_nl_get_pd_size() immediately dereferences pd->cpus
(struct offset 0x30), causing a null-pointer dereference.
The sister handler dev_energymodel_nl_get_perf_table_doit() already
handles this correctly via __em_nl_get_pd_table_id(), which returns
NULL and causes the caller to return -EINVAL. Add the same NULL check
in the get-perf-domains do handler.
Fixes: 380ff27af25e ("PM: EM: Add dump to get-perf-domains in the EM YNL spec")
Reported-by: Yi Lai <yi1.lai@linux.intel.com>
Closes: https://lore.kernel.org/lkml/aXiySM79UYfk+ytd@ly-workstation/
Signed-off-by: Changwoo Min <changwoo@igalia.com>
---
kernel/power/em_netlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/power/em_netlink.c b/kernel/power/em_netlink.c
index 5a611d3950fd..4d4fd29bd2be 100644
--- a/kernel/power/em_netlink.c
+++ b/kernel/power/em_netlink.c
@@ -109,6 +109,8 @@ int dev_energymodel_nl_get_perf_domains_doit(struct sk_buff *skb,
id = nla_get_u32(info->attrs[DEV_ENERGYMODEL_A_PERF_DOMAIN_PERF_DOMAIN_ID]);
pd = em_perf_domain_get_by_id(id);
+ if (!pd)
+ return -EINVAL;
__em_nl_get_pd_size(pd, &msg_sz);
msg = genlmsg_new(msg_sz, GFP_KERNEL);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 5/5] regulator: sc2731: Add platform_device_id table
From: Otto Pflüger @ 2026-03-29 7:27 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger
In-Reply-To: <20260329-sc27xx-mfd-cells-v3-0-9158dee41f74@abscue.de>
Make the regulator driver for the SC2731 PMIC probe automatically. Using
a platform_device_id table instead of DT compatible matching avoids the
need for a separate compatible property in the "regulators" node, which
simplifies the DT bindings and makes the parent MFD device responsible
for selecting the correct regulator driver for the PMIC.
However, this means that the regulator device is not automatically
associated with the "regulators" node. Tell the regulator core to
perform device tree lookups using the parent MFD device instead of
the regulator sub-device and set the .regulators_node member in all
regulator definitions so that the "regulators" sub-node is used.
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
---
drivers/regulator/sc2731-regulator.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/sc2731-regulator.c b/drivers/regulator/sc2731-regulator.c
index 5447e1a47d15..93c8156c5110 100644
--- a/drivers/regulator/sc2731-regulator.c
+++ b/drivers/regulator/sc2731-regulator.c
@@ -131,6 +131,7 @@ static const struct regulator_ops sc2731_regu_linear_ops = {
vstep, vmin, vmax) { \
.name = #_id, \
.of_match = of_match_ptr(#_id), \
+ .regulators_node = of_match_ptr("regulators"), \
.ops = &sc2731_regu_linear_ops, \
.type = REGULATOR_VOLTAGE, \
.id = SC2731_##_id, \
@@ -226,7 +227,7 @@ static int sc2731_regulator_probe(struct platform_device *pdev)
return ret;
}
- config.dev = &pdev->dev;
+ config.dev = pdev->dev.parent;
config.regmap = regmap;
for (i = 0; i < ARRAY_SIZE(regulators); i++) {
@@ -242,12 +243,19 @@ static int sc2731_regulator_probe(struct platform_device *pdev)
return 0;
}
+static const struct platform_device_id sc2731_regulator_id_table[] = {
+ { "sc2731-regulator" },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, sc2731_regulator_id_table);
+
static struct platform_driver sc2731_regulator_driver = {
.driver = {
.name = "sc27xx-regulator",
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
.probe = sc2731_regulator_probe,
+ .id_table = sc2731_regulator_id_table,
};
module_platform_driver(sc2731_regulator_driver);
--
2.51.0
^ permalink raw reply related
* [PATCH v3 4/5] power: reset: sc27xx: Add platform_device_id table
From: Otto Pflüger @ 2026-03-29 7:27 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger, Sebastian Reichel
In-Reply-To: <20260329-sc27xx-mfd-cells-v3-0-9158dee41f74@abscue.de>
Make the poweroff driver for SC27xx-series PMICs probe automatically.
Since the device representing the poweroff functionality of the SC27xx
PMIC is not supposed to have a dedicated device tree node without any
corresponding DT resources [1], an of_device_id table cannot be used
here. Instead, use a platform_device_id table to match the poweroff
sub-device instantiated by the parent MFD driver.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
[1]: https://lore.kernel.org/all/20251002025344.GA2958334-robh@kernel.org/
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/power/reset/sc27xx-poweroff.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/power/reset/sc27xx-poweroff.c b/drivers/power/reset/sc27xx-poweroff.c
index 393bd1c33b73..6376706bf561 100644
--- a/drivers/power/reset/sc27xx-poweroff.c
+++ b/drivers/power/reset/sc27xx-poweroff.c
@@ -6,6 +6,7 @@
#include <linux/cpu.h>
#include <linux/kernel.h>
+#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/pm.h>
@@ -70,11 +71,18 @@ static int sc27xx_poweroff_probe(struct platform_device *pdev)
return 0;
}
+static const struct platform_device_id sc27xx_poweroff_id_table[] = {
+ { "sc2731-poweroff" },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, sc27xx_poweroff_id_table);
+
static struct platform_driver sc27xx_poweroff_driver = {
.probe = sc27xx_poweroff_probe,
.driver = {
.name = "sc27xx-poweroff",
},
+ .id_table = sc27xx_poweroff_id_table,
};
module_platform_driver(sc27xx_poweroff_driver);
--
2.51.0
^ permalink raw reply related
* [PATCH v3 3/5] mfd: sprd-sc27xx: Switch to devm_mfd_add_devices()
From: Otto Pflüger @ 2026-03-29 7:27 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger
In-Reply-To: <20260329-sc27xx-mfd-cells-v3-0-9158dee41f74@abscue.de>
To allow instantiating subdevices such as the regulator and poweroff
devices that do not have corresponding device tree nodes with a
"compatible" property, use devm_mfd_add_devices() with MFD cells instead
of devm_of_platform_populate(). Since different PMICs in the SC27xx
series contain different components, use separate MFD cell tables for
each PMIC model. Define cells for all components that have upstream
drivers at this point.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
---
drivers/mfd/sprd-sc27xx-spi.c | 62 ++++++++++++++++++++++++++++++++++++-------
1 file changed, 53 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
index d6b4350779e6..aa052f646623 100644
--- a/drivers/mfd/sprd-sc27xx-spi.c
+++ b/drivers/mfd/sprd-sc27xx-spi.c
@@ -14,6 +14,11 @@
#include <linux/spi/spi.h>
#include <uapi/linux/usb/charger.h>
+enum sprd_pmic_type {
+ PMIC_TYPE_SC2730 = 1,
+ PMIC_TYPE_SC2731,
+};
+
#define SPRD_PMIC_INT_MASK_STATUS 0x0
#define SPRD_PMIC_INT_RAW_STATUS 0x4
#define SPRD_PMIC_INT_EN 0x8
@@ -50,6 +55,29 @@ struct sprd_pmic_data {
u32 charger_det;
};
+static const struct mfd_cell sc2730_devices[] = {
+ MFD_CELL_OF("sc2730-adc", NULL, NULL, 0, 0, "sprd,sc2730-adc"),
+ MFD_CELL_OF("sc2730-bltc", NULL, NULL, 0, 0, "sprd,sc2730-bltc"),
+ MFD_CELL_OF("sc2730-efuse", NULL, NULL, 0, 0, "sprd,sc2730-efuse"),
+ MFD_CELL_OF("sc2730-eic", NULL, NULL, 0, 0, "sprd,sc2730-eic"),
+ MFD_CELL_OF("sc2730-fgu", NULL, NULL, 0, 0, "sprd,sc2730-fgu"),
+ MFD_CELL_OF("sc2730-rtc", NULL, NULL, 0, 0, "sprd,sc2730-rtc"),
+ MFD_CELL_OF("sc2730-vibrator", NULL, NULL, 0, 0, "sprd,sc2730-vibrator"),
+};
+
+static const struct mfd_cell sc2731_devices[] = {
+ MFD_CELL_OF("sc2731-adc", NULL, NULL, 0, 0, "sprd,sc2731-adc"),
+ MFD_CELL_OF("sc2731-bltc", NULL, NULL, 0, 0, "sprd,sc2731-bltc"),
+ MFD_CELL_OF("sc2731-charger", NULL, NULL, 0, 0, "sprd,sc2731-charger"),
+ MFD_CELL_OF("sc2731-efuse", NULL, NULL, 0, 0, "sprd,sc2731-efuse"),
+ MFD_CELL_OF("sc2731-eic", NULL, NULL, 0, 0, "sprd,sc2731-eic"),
+ MFD_CELL_OF("sc2731-fgu", NULL, NULL, 0, 0, "sprd,sc2731-fgu"),
+ MFD_CELL_NAME("sc2731-poweroff"),
+ MFD_CELL_NAME("sc2731-regulator"),
+ MFD_CELL_OF("sc2731-rtc", NULL, NULL, 0, 0, "sprd,sc2731-rtc"),
+ MFD_CELL_OF("sc2731-vibrator", NULL, NULL, 0, 0, "sprd,sc2731-vibrator"),
+};
+
/*
* Since different PMICs of SC27xx series can have different interrupt
* base address and irq number, we should save irq number and irq base
@@ -152,12 +180,26 @@ static const struct regmap_config sprd_pmic_config = {
static int sprd_pmic_probe(struct spi_device *spi)
{
struct sprd_pmic *ddata;
+ enum sprd_pmic_type pmic_type;
const struct sprd_pmic_data *pdata;
- int ret, i;
+ const struct mfd_cell *cells;
+ int ret, i, num_cells;
+
+ pmic_type = (uintptr_t)of_device_get_match_data(&spi->dev);
- pdata = of_device_get_match_data(&spi->dev);
- if (!pdata) {
- dev_err(&spi->dev, "No matching driver data found\n");
+ switch (pmic_type) {
+ case PMIC_TYPE_SC2730:
+ pdata = &sc2730_data;
+ cells = sc2730_devices;
+ num_cells = ARRAY_SIZE(sc2730_devices);
+ break;
+ case PMIC_TYPE_SC2731:
+ pdata = &sc2731_data;
+ cells = sc2731_devices;
+ num_cells = ARRAY_SIZE(sc2731_devices);
+ break;
+ default:
+ dev_err(&spi->dev, "Invalid device ID\n");
return -EINVAL;
}
@@ -204,7 +246,9 @@ static int sprd_pmic_probe(struct spi_device *spi)
return ret;
}
- ret = devm_of_platform_populate(&spi->dev);
+ ret = devm_mfd_add_devices(&spi->dev, PLATFORM_DEVID_AUTO,
+ cells, num_cells, NULL, 0,
+ regmap_irq_get_domain(ddata->irq_data));
if (ret) {
dev_err(&spi->dev, "Failed to populate sub-devices %d\n", ret);
return ret;
@@ -241,15 +285,15 @@ static DEFINE_SIMPLE_DEV_PM_OPS(sprd_pmic_pm_ops,
sprd_pmic_suspend, sprd_pmic_resume);
static const struct of_device_id sprd_pmic_match[] = {
- { .compatible = "sprd,sc2730", .data = &sc2730_data },
- { .compatible = "sprd,sc2731", .data = &sc2731_data },
+ { .compatible = "sprd,sc2730", .data = (void *)PMIC_TYPE_SC2730 },
+ { .compatible = "sprd,sc2731", .data = (void *)PMIC_TYPE_SC2731 },
{},
};
MODULE_DEVICE_TABLE(of, sprd_pmic_match);
static const struct spi_device_id sprd_pmic_spi_ids[] = {
- { .name = "sc2730", .driver_data = (unsigned long)&sc2730_data },
- { .name = "sc2731", .driver_data = (unsigned long)&sc2731_data },
+ { .name = "sc2730", .driver_data = PMIC_TYPE_SC2730 },
+ { .name = "sc2731", .driver_data = PMIC_TYPE_SC2731 },
{},
};
MODULE_DEVICE_TABLE(spi, sprd_pmic_spi_ids);
--
2.51.0
^ permalink raw reply related
* [PATCH v3 2/5] regulator: dt-bindings: sc2731: Deprecate compatible property
From: Otto Pflüger @ 2026-03-29 7:27 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger
In-Reply-To: <20260329-sc27xx-mfd-cells-v3-0-9158dee41f74@abscue.de>
The node containing the regulators is always a child of the main PMIC
node, which already has a compatible property identifying the type of
PMIC. This makes the compatible in the child node redundant. Mark it
as deprecated and remove it from the required property list and the
examples.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
---
Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml | 2 --
.../devicetree/bindings/regulator/sprd,sc2731-regulator.yaml | 4 +---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
index b023e1ef8d3c..12b3258daef5 100644
--- a/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
+++ b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
@@ -222,8 +222,6 @@ examples:
};
regulators {
- compatible = "sprd,sc2731-regulator";
-
BUCK_CPU0 {
regulator-name = "vddarm0";
regulator-min-microvolt = <400000>;
diff --git a/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml
index 9bd752bab68e..7af20a4781b7 100644
--- a/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml
@@ -26,6 +26,7 @@ description: |
properties:
compatible:
+ deprecated: true
const: sprd,sc2731-regulator
patternProperties:
@@ -39,8 +40,5 @@ patternProperties:
$ref: regulator.yaml#
unevaluatedProperties: false
-required:
- - compatible
-
additionalProperties: false
...
--
2.51.0
^ permalink raw reply related
* [PATCH v3 1/5] dt-bindings: rtc: sc2731: Add compatible for SC2730
From: Otto Pflüger @ 2026-03-29 7:27 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger
In-Reply-To: <20260329-sc27xx-mfd-cells-v3-0-9158dee41f74@abscue.de>
The RTC block found in the SC2730 PMIC is compatible with the one found
in the SC2731 PMIC.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
---
Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
index 5756f617df36..1deae2f4f09d 100644
--- a/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
@@ -13,7 +13,12 @@ maintainers:
properties:
compatible:
- const: sprd,sc2731-rtc
+ oneOf:
+ - items:
+ - enum:
+ - sprd,sc2730-rtc
+ - const: sprd,sc2731-rtc
+ - const: sprd,sc2731-rtc
reg:
maxItems: 1
--
2.51.0
^ permalink raw reply related
* [PATCH v3 0/5] mfd: sc27xx: Use MFD cells and devm_mfd_add_devices()
From: Otto Pflüger @ 2026-03-29 7:27 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger, Sebastian Reichel
These changes resulted from the need to decouple the the Linux device
driver hierarchy from the device tree bindings for two different series
introducing regulator [1] and poweroff [2] support for the SC2730 PMIC.
There are different PMICs in the SC27xx series, including SC2730 and
SC2731. These have a lot of similarities, but some differences too. For
instance, they contain compatible RTC blocks, but completely different
sets of regulators.
On the Linux side, each PMIC block needs its own driver. The MFD driver
currently uses devm_of_platform_populate() to load the drivers for the
components of the PMIC, which only works when each component has its own
sub-node with a "compatible" property that is used to select a driver
for the device.
When viewed from the device tree side, the parent node representing the
PMIC already contains a "compatible" property that distinguishes the
different PMICs. While the device tree bindings currently do require a
separate "compatible" property for each sub-node (ADC, fuel gauge,
regulators, ...), this is essentially redundant since the node name and
the parent compatible uniquely identify the component. Moreover, some
parts of the PMIC such as the poweroff/reboot controller do not even
need a corresponding device tree node.
Change the MFD driver to use MFD cells instead, which allows it to
instantiate sub-devices both with and without device tree nodes.
Devices that do not have a separate device tree node with its own
"compatible" property can be matched by their platform device ID.
Use this to hook up the existing SC2731 poweroff and regulator drivers,
which were previously not loaded at all due to the lack of an ID table.
In the device tree bindings, deprecate the redundant "compatible"
property for the "regulators" node. While it might make sense to do this
for the other components too, there are a few reasons to only change the
regulators at this point:
- The regulators node is special since it is not as independent as the
other components. For instance, it is the only child node of the PMIC
that does not have a "reg" property. The set of regulators also
differs much more between different PMIC models than the register
layout of the other components.
- We already have some other PMICs where only the regulators are
treated specially like this, such as MediaTek MT6359 and MT6370.
- It was suggested to remove the "compatible" property for the new
SC2730 regulator bindings I am preparing in [2]. The bindings for
the other components do not need any significant changes at the
moment.
- Unlike the poweroff and regulator components, the other parts are
already working with the existing drivers and bindings.
For the other components that still have a "compatible" property used
for matching MFD cells, ensure that an SC2730-specific compatible is
defined in the bindings so that it can be listed in the SC2730-specific
device table in the MFD driver.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
[1]: https://lore.kernel.org/all/20250926-sc2730-reboot-v1-0-62ebfd3d31bb@abscue.de/
[2]: https://lore.kernel.org/all/20260220-sc2730-regulators-v1-0-3f2bbc9ecf14@abscue.de/
---
Changes in v3:
- Fixed warning about pointer-to-integer cast by using uintptr_t.
- Changed device ID enum to start with 1 so that 0 is invalid.
- Link to v2: https://lore.kernel.org/r/20260325-sc27xx-mfd-cells-v2-0-d0ebb60aa4a7@abscue.de
Changes in v2:
- Changed PMIC type matching in MFD driver to use an identifier like
other drivers instead of passing pointers through of_device_id.
- Rebased on next-20260324.
- Link to v1: https://lore.kernel.org/r/20260222-sc27xx-mfd-cells-v1-0-69526fe74c77@abscue.de
---
Otto Pflüger (5):
dt-bindings: rtc: sc2731: Add compatible for SC2730
regulator: dt-bindings: sc2731: Deprecate compatible property
mfd: sprd-sc27xx: Switch to devm_mfd_add_devices()
power: reset: sc27xx: Add platform_device_id table
regulator: sc2731: Add platform_device_id table
.../devicetree/bindings/mfd/sprd,sc2731.yaml | 2 -
.../bindings/regulator/sprd,sc2731-regulator.yaml | 4 +-
.../devicetree/bindings/rtc/sprd,sc2731-rtc.yaml | 7 ++-
drivers/mfd/sprd-sc27xx-spi.c | 62 ++++++++++++++++++----
drivers/power/reset/sc27xx-poweroff.c | 8 +++
drivers/regulator/sc2731-regulator.c | 10 +++-
6 files changed, 77 insertions(+), 16 deletions(-)
---
base-commit: 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c
change-id: 20260221-sc27xx-mfd-cells-dab7905f3aae
Best regards,
--
Otto Pflüger <otto.pflueger@abscue.de>
^ permalink raw reply
* [PATCH v2 2/2] thermal: intel: int340x: Check return value of ptc_create_groups()
From: aravindanilraj0702 @ 2026-03-29 7:06 UTC (permalink / raw)
To: rafael
Cc: daniel.lezcano, rui.zhang, lukasz.luba, srinivas.pandruvada,
linux-pm, linux-kernel, Aravind Anilraj
In-Reply-To: <20260329070642.10721-1-aravindanilraj0702@gmail.com>
From: Aravind Anilraj <aravindanilraj0702@gmail.com>
proc_thermal_ptc_add() ignores the return value of ptc_create_groups(),
causing the driver to silenty continue even if sysfs group creation
fails. The thermal control interface would be unavailable with no
indication of failure.
Check the return value and on failure clean up any sysfs groups that
were successfully created before the error, then propagate the error to
the caller which already handles it correctly via goto err_rem_rapl.
Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>
---
.../int340x_thermal/platform_temperature_control.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
index 18ac5014d8dc..d92a6f84a778 100644
--- a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
+++ b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
@@ -278,12 +278,18 @@ static void ptc_delete_debugfs(void)
int proc_thermal_ptc_add(struct pci_dev *pdev, struct proc_thermal_device *proc_priv)
{
if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_PTC) {
- int i;
+ int i, ret;
for (i = 0; i < PTC_MAX_INSTANCES; i++) {
ptc_instance[i].offset = ptc_offsets[i];
ptc_instance[i].pdev = pdev;
- ptc_create_groups(pdev, i, &ptc_instance[i]);
+ ret = ptc_create_groups(pdev, i, &ptc_instance[i]);
+ if (ret) {
+ while (i--)
+ sysfs_remove_group(&pdev->dev.kobj,
+ &ptc_instance[i].ptc_attr_group);
+ return ret;
+ }
}
ptc_create_debugfs();
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/2] thermal: intel: int340x: Fix potential shift overflow in ptc_mmio_write
From: aravindanilraj0702 @ 2026-03-29 7:06 UTC (permalink / raw)
To: rafael
Cc: daniel.lezcano, rui.zhang, lukasz.luba, srinivas.pandruvada,
linux-pm, linux-kernel, Aravind Anilraj
In-Reply-To: <20260329070642.10721-1-aravindanilraj0702@gmail.com>
From: Aravind Anilraj <aravindanilraj0702@gmail.com>
The value parameter is u32 but is shifted into a u64 register value
without casting first. If the shift amount pushes bits beyond 32, they
are lost. Cast value to u64 before shifting to ensure all bits are
preserved.
Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>
---
.../intel/int340x_thermal/platform_temperature_control.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
index 0ccc72c93499..18ac5014d8dc 100644
--- a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
+++ b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
@@ -138,7 +138,7 @@ static void ptc_mmio_write(struct pci_dev *pdev, u32 offset, int index, u32 valu
reg_val = readq((void __iomem *) (proc_priv->mmio_base + offset));
reg_val &= ~mask;
- reg_val |= (value << ptc_mmio_regs[index].shift);
+ reg_val |= ((u64)value << ptc_mmio_regs[index].shift);
writeq(reg_val, (void __iomem *) (proc_priv->mmio_base + offset));
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/2] thermal: intel: int340x platform temperature
From: aravindanilraj0702 @ 2026-03-29 7:06 UTC (permalink / raw)
To: rafael
Cc: daniel.lezcano, rui.zhang, lukasz.luba, srinivas.pandruvada,
linux-pm, linux-kernel, Aravind Anilraj
From: Aravind Anilraj <aravindanilraj0702@gmail.com>
This series fixes two issues in the Intel int340x platform temperature
control driver.
Patch 1 fixes a potential shift overflow where a u32 value is shifted
into a u64 register without casting, which may lead to incorrect
hardware configuration.
Patch 2 checks the return value of ptc_create_groups() and ensures
proper cleanup of previously created sysfs groups on error.
Changes in v2:
Patch 1: No changes.
Patch 2: Add missing sysfs cleanup loop in error path.
Aravind Anilraj (2):
thermal: intel: int340x: Fix potential shift overflow in
ptc_mmio_write
thermal: intel: int340x: Check return value of ptc_create_groups()
.../int340x_thermal/platform_temperature_control.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-1-krishnagopi487@gmail.com>
st,thermal-flags is a required property in SPEAr Thermal Sensor node,
which is incorrectly written as thermal_flags in spear13xx.dtsi.
Rename thermal_flags to st,thermal-flags to fix the property name
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v1:
- Reword the commit message and subject
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
arch/arm/boot/dts/st/spear13xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 159e941708ca..97357680dd51 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -332,7 +332,7 @@ wdt@ec800620 {
thermal@e07008c4 {
compatible = "st,thermal-spear1340";
reg = <0xe07008c4 0x4>;
- thermal_flags = <0x7000>;
+ st,thermal-flags = <0x7000>;
};
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-1-krishnagopi487@gmail.com>
Convert the SPEAr Thermal Sensor bindings to DT schema.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v1:
- Changed unevaluatedProperties to additionalProperties
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
2 files changed, 36 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt
deleted file mode 100644
index 93e3b67c102d..000000000000
--- a/Documentation/devicetree/bindings/thermal/spear-thermal.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* SPEAr Thermal
-
-Required properties:
-- compatible : "st,thermal-spear1340"
-- reg : Address range of the thermal registers
-- st,thermal-flags: flags used to enable thermal sensor
-
-Example:
-
- thermal@fc000000 {
- compatible = "st,thermal-spear1340";
- reg = <0xfc000000 0x1000>;
- st,thermal-flags = <0x7000>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
new file mode 100644
index 000000000000..e3462a974691
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr Thermal Sensor
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+
+properties:
+ compatible:
+ const: st,thermal-spear1340
+
+ reg:
+ maxItems: 1
+
+ st,thermal-flags:
+ description: flags used to enable thermal sensor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - st,thermal-flags
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal@fc000000 {
+ compatible = "st,thermal-spear1340";
+ reg = <0xfc000000 0x1000>;
+ st,thermal-flags = <0x7000>;
+ };
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
This patch series converts SPEAr Thermal Sensor bindings to DT schema
and corrects the thermal_flags property in spear13xx.dtsi to
st,thermal-flags.
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Gopi Krishna Menon (2):
dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
arch/arm/boot/dts/st/spear13xx.dtsi | 2 +-
3 files changed, 37 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
--
2.52.0
^ permalink raw reply
* Re: [PATCH v2 3/5] mfd: sprd-sc27xx: Switch to devm_mfd_add_devices()
From: kernel test robot @ 2026-03-29 2:43 UTC (permalink / raw)
To: Otto Pflüger, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Orson Zhai, Baolin Wang,
Chunyan Zhang, Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Sebastian Reichel
Cc: llvm, oe-kbuild-all, linux-rtc, devicetree, linux-kernel,
linux-leds, linux-pm, Otto Pflüger
In-Reply-To: <20260325-sc27xx-mfd-cells-v2-3-d0ebb60aa4a7@abscue.de>
Hi Otto,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c]
url: https://github.com/intel-lab-lkp/linux/commits/Otto-Pfl-ger/dt-bindings-rtc-sc2731-Add-compatible-for-SC2730/20260327-162827
base: 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c
patch link: https://lore.kernel.org/r/20260325-sc27xx-mfd-cells-v2-3-d0ebb60aa4a7%40abscue.de
patch subject: [PATCH v2 3/5] mfd: sprd-sc27xx: Switch to devm_mfd_add_devices()
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260329/202603291013.6DnmGjG3-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 054e11d1a17e5ba88bb1a8ef32fad3346e80b186)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260329/202603291013.6DnmGjG3-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603291013.6DnmGjG3-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/mfd/sprd-sc27xx-spi.c:188:14: warning: cast to smaller integer type 'enum sprd_pmic_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
188 | pmic_type = (enum sprd_pmic_type)of_device_get_match_data(&spi->dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +188 drivers/mfd/sprd-sc27xx-spi.c
179
180 static int sprd_pmic_probe(struct spi_device *spi)
181 {
182 struct sprd_pmic *ddata;
183 enum sprd_pmic_type pmic_type;
184 const struct sprd_pmic_data *pdata;
185 const struct mfd_cell *cells;
186 int ret, i, num_cells;
187
> 188 pmic_type = (enum sprd_pmic_type)of_device_get_match_data(&spi->dev);
189
190 switch (pmic_type) {
191 case PMIC_TYPE_SC2730:
192 pdata = &sc2730_data;
193 cells = sc2730_devices;
194 num_cells = ARRAY_SIZE(sc2730_devices);
195 break;
196 case PMIC_TYPE_SC2731:
197 pdata = &sc2731_data;
198 cells = sc2731_devices;
199 num_cells = ARRAY_SIZE(sc2731_devices);
200 break;
201 default:
202 dev_err(&spi->dev, "Invalid device ID\n");
203 return -EINVAL;
204 }
205
206 ddata = devm_kzalloc(&spi->dev, sizeof(*ddata), GFP_KERNEL);
207 if (!ddata)
208 return -ENOMEM;
209
210 ddata->regmap = devm_regmap_init(&spi->dev, &sprd_pmic_regmap,
211 &spi->dev, &sprd_pmic_config);
212 if (IS_ERR(ddata->regmap)) {
213 ret = PTR_ERR(ddata->regmap);
214 dev_err(&spi->dev, "Failed to allocate register map %d\n", ret);
215 return ret;
216 }
217
218 spi_set_drvdata(spi, ddata);
219 ddata->dev = &spi->dev;
220 ddata->irq = spi->irq;
221 ddata->pdata = pdata;
222
223 ddata->irq_chip.name = dev_name(&spi->dev);
224 ddata->irq_chip.status_base =
225 pdata->irq_base + SPRD_PMIC_INT_MASK_STATUS;
226 ddata->irq_chip.unmask_base = pdata->irq_base + SPRD_PMIC_INT_EN;
227 ddata->irq_chip.ack_base = 0;
228 ddata->irq_chip.num_regs = 1;
229 ddata->irq_chip.num_irqs = pdata->num_irqs;
230
231 ddata->irqs = devm_kcalloc(&spi->dev,
232 pdata->num_irqs, sizeof(struct regmap_irq),
233 GFP_KERNEL);
234 if (!ddata->irqs)
235 return -ENOMEM;
236
237 ddata->irq_chip.irqs = ddata->irqs;
238 for (i = 0; i < pdata->num_irqs; i++)
239 ddata->irqs[i].mask = BIT(i);
240
241 ret = devm_regmap_add_irq_chip(&spi->dev, ddata->regmap, ddata->irq,
242 IRQF_ONESHOT, 0,
243 &ddata->irq_chip, &ddata->irq_data);
244 if (ret) {
245 dev_err(&spi->dev, "Failed to add PMIC irq chip %d\n", ret);
246 return ret;
247 }
248
249 ret = devm_mfd_add_devices(&spi->dev, PLATFORM_DEVID_AUTO,
250 cells, num_cells, NULL, 0,
251 regmap_irq_get_domain(ddata->irq_data));
252 if (ret) {
253 dev_err(&spi->dev, "Failed to populate sub-devices %d\n", ret);
254 return ret;
255 }
256
257 ret = devm_device_init_wakeup(&spi->dev);
258 if (ret)
259 return dev_err_probe(&spi->dev, ret, "Failed to init wakeup\n");
260
261 return 0;
262 }
263
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Sebastian Reichel @ 2026-03-29 2:09 UTC (permalink / raw)
To: Linus Walleij
Cc: Krzysztof Kozlowski, Rob Herring (Arm), Khushal Chitturi,
devicetree, linux-kernel, linux-pm, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <CAD++jLnxoS-OGBSAXxgGPaME7eMTwCQ-C+uzub6m0o9ZgXL_aA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]
Hi,
On Sat, Mar 28, 2026 at 10:28:39PM +0100, Linus Walleij wrote:
> On Sat, Mar 28, 2026 at 6:31 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On 28/03/2026 17:12, Linus Walleij wrote:
> > > On Sat, Mar 28, 2026 at 3:26 PM Rob Herring (Arm) <robh@kernel.org> wrote:
> > >
> > >> dtschema/dtc warnings/errors:
> > >> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.example.dtb: power-controller@4b000000 (cortina,gemini-power-controller): '#power-domain-cells' is a required property
> > >> from schema $id: http://devicetree.org/schemas/power/power-domain.yaml
> > >
> > > Weird, this power controller does not handle power domains whatsoever,
> > > it handles the mains power. So it should not have any power domain
> > > cells.
> > >
> > > Is this the result of some regexp gone stray?
> >
> > The name "power controller" is used for power domain controller, so
> > that's why this name must not be used for other use cases. Usual
> > replacement is power-management, reboot, restart or poweroff, depending
> > on what is the purpose of this device.
>
> So in this case this is just a conversion of the 9 years old text document
> which is an as valid binding as any:
>
> commit ba443b5ab454a9b5f49229a94b2dadf06ac8b79e
> Author: Linus Walleij <linusw@kernel.org>
> Date: Sun Mar 12 23:36:01 2017 +0100
>
> power: reset: Add Gemini poweroff DT bindings
>
> This adds device tree bindings to the power management controller
> in the Gemini SoC.
>
> Cc: devicetree@vger.kernel.org
> Cc: Janos Laube <janos.dev@gmail.com>
> Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
> Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
>
> The text document was conspiciously named "gemini-poweroff.txt" while the
> compatible is ""cortina,gemini-power-controller".
>
> I don't know what came first, this binding or the convention of
> *-power-controller, but it's solidly there for a while so we need
> to accomodate this, I guess worst case simply special-casing it?
The problem is the node name (power-controller@4b000000), which is
reserved for power domains. You can keep the compatible.
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Linus Walleij @ 2026-03-28 21:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring (Arm), Khushal Chitturi, devicetree, linux-kernel,
linux-pm, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
In-Reply-To: <3fa4fad0-d918-4de0-ad80-dad2141d2617@kernel.org>
On Sat, Mar 28, 2026 at 6:31 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 28/03/2026 17:12, Linus Walleij wrote:
> > On Sat, Mar 28, 2026 at 3:26 PM Rob Herring (Arm) <robh@kernel.org> wrote:
> >
> >> dtschema/dtc warnings/errors:
> >> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.example.dtb: power-controller@4b000000 (cortina,gemini-power-controller): '#power-domain-cells' is a required property
> >> from schema $id: http://devicetree.org/schemas/power/power-domain.yaml
> >
> > Weird, this power controller does not handle power domains whatsoever,
> > it handles the mains power. So it should not have any power domain
> > cells.
> >
> > Is this the result of some regexp gone stray?
>
> The name "power controller" is used for power domain controller, so
> that's why this name must not be used for other use cases. Usual
> replacement is power-management, reboot, restart or poweroff, depending
> on what is the purpose of this device.
So in this case this is just a conversion of the 9 years old text document
which is an as valid binding as any:
commit ba443b5ab454a9b5f49229a94b2dadf06ac8b79e
Author: Linus Walleij <linusw@kernel.org>
Date: Sun Mar 12 23:36:01 2017 +0100
power: reset: Add Gemini poweroff DT bindings
This adds device tree bindings to the power management controller
in the Gemini SoC.
Cc: devicetree@vger.kernel.org
Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The text document was conspiciously named "gemini-poweroff.txt" while the
compatible is ""cortina,gemini-power-controller".
I don't know what came first, this binding or the convention of
*-power-controller,
but it's solidly there for a while so we need to accomodate this, I guess worst
case simply special-casing it?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] thermal: intel: int340x: Check return value of ptc_create_groups()
From: aravindanilraj0702 @ 2026-03-28 19:18 UTC (permalink / raw)
To: rafael, linux-pm
Cc: daniel.lezcano, rui.zhang, lukasz.luba, srinivas.pandruvada,
linux-kernel, Aravind Anilraj
In-Reply-To: <20260328191806.8675-1-aravindanilraj0702@gmail.com>
From: Aravind Anilraj <aravindanilraj0702@gmail.com>
proc_thermal_ptc_add() ignores the return value of ptc_create_groups(),
causing the driver to silenty continue even if sysfs group creation
fails. The thermal control interface would be unavailable with no
indication of failure.
Check the return value and on failure clean up any sysfs groups that
were successfully created before the error, then propagate the error to
the caller which already handles it correctly via goto err_rem_rapl.
Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>
---
.../intel/int340x_thermal/platform_temperature_control.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
index 18ac5014d8dc..caed572c6061 100644
--- a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
+++ b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
@@ -278,12 +278,14 @@ static void ptc_delete_debugfs(void)
int proc_thermal_ptc_add(struct pci_dev *pdev, struct proc_thermal_device *proc_priv)
{
if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_PTC) {
- int i;
+ int i, ret;
for (i = 0; i < PTC_MAX_INSTANCES; i++) {
ptc_instance[i].offset = ptc_offsets[i];
ptc_instance[i].pdev = pdev;
- ptc_create_groups(pdev, i, &ptc_instance[i]);
+ ret = ptc_create_groups(pdev, i, &ptc_instance[i]);
+ if (ret)
+ return ret;
}
ptc_create_debugfs();
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] thermal: intel: int340x: Fix potential shift overflow in ptc_mmio_write
From: aravindanilraj0702 @ 2026-03-28 19:18 UTC (permalink / raw)
To: rafael, linux-pm
Cc: daniel.lezcano, rui.zhang, lukasz.luba, srinivas.pandruvada,
linux-kernel, Aravind Anilraj
In-Reply-To: <20260328191806.8675-1-aravindanilraj0702@gmail.com>
From: Aravind Anilraj <aravindanilraj0702@gmail.com>
The value parameter is u32 but is shifted into a u64 register value
without casting first. If the shift amount pushes bits beyond 32, they
are lost. Cast value to u64 before shifting to ensure all bits are
preserved.
Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>
---
.../intel/int340x_thermal/platform_temperature_control.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
index 0ccc72c93499..18ac5014d8dc 100644
--- a/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
+++ b/drivers/thermal/intel/int340x_thermal/platform_temperature_control.c
@@ -138,7 +138,7 @@ static void ptc_mmio_write(struct pci_dev *pdev, u32 offset, int index, u32 valu
reg_val = readq((void __iomem *) (proc_priv->mmio_base + offset));
reg_val &= ~mask;
- reg_val |= (value << ptc_mmio_regs[index].shift);
+ reg_val |= ((u64)value << ptc_mmio_regs[index].shift);
writeq(reg_val, (void __iomem *) (proc_priv->mmio_base + offset));
}
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] thermal: intel: int340x: Fix bugs in
From: aravindanilraj0702 @ 2026-03-28 19:18 UTC (permalink / raw)
To: rafael, linux-pm
Cc: daniel.lezcano, rui.zhang, lukasz.luba, srinivas.pandruvada,
linux-kernel, Aravind Anilraj
From: Aravind Anilraj <aravindanilraj0702@gmail.com>
This series fixes two issues in the Intel int340x platform temperature
control driver.
Patch 1 fixes a potential shift overflow where a u32 value is shifted
into a u64 register without casting, leading to incorrect results.
Patch 2 checks and propagates the return value of ptc_create_groups() in
proc_thermal_ptc_add(). It also ensures proper cleanup of any previously
created sysfs groups on the error path.
Aravind Anilraj (2):
thermal: intel: int340x: Fix potential shift overflow in
ptc_mmio_write
thermal: intel: int340x: Check return value of ptc_create_groups()
.../intel/int340x_thermal/platform_temperature_control.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-28 17:31 UTC (permalink / raw)
To: Linus Walleij, Rob Herring (Arm)
Cc: Khushal Chitturi, devicetree, linux-kernel, linux-pm,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
In-Reply-To: <CAD++jL=_rCmW=eSV0kvck50sC2xaQnGQoEOy=DNcwkFvvWYUUw@mail.gmail.com>
On 28/03/2026 17:12, Linus Walleij wrote:
> On Sat, Mar 28, 2026 at 3:26 PM Rob Herring (Arm) <robh@kernel.org> wrote:
>
>> dtschema/dtc warnings/errors:
>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.example.dtb: power-controller@4b000000 (cortina,gemini-power-controller): '#power-domain-cells' is a required property
>> from schema $id: http://devicetree.org/schemas/power/power-domain.yaml
>
> Weird, this power controller does not handle power domains whatsoever,
> it handles the mains power. So it should not have any power domain
> cells.
>
> Is this the result of some regexp gone stray?
The name "power controller" is used for power domain controller, so
that's why this name must not be used for other use cases. Usual
replacement is power-management, reboot, restart or poweroff, depending
on what is the purpose of this device.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Linus Walleij @ 2026-03-28 16:12 UTC (permalink / raw)
To: Khushal Chitturi
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-pm, devicetree, linux-kernel
In-Reply-To: <20260328124707.141209-1-khushalchitturi@gmail.com>
On Sat, Mar 28, 2026 at 1:47 PM Khushal Chitturi
<khushalchitturi@gmail.com> wrote:
> Convert the Cortina Systems Gemini Poweroff Controller bindings to
> DT schema.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
Looks good to me, and thanks for looking into this!
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Linus Walleij @ 2026-03-28 16:12 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Khushal Chitturi, devicetree, linux-kernel, linux-pm,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
In-Reply-To: <177470797266.1536342.6967120656934552033.robh@kernel.org>
On Sat, Mar 28, 2026 at 3:26 PM Rob Herring (Arm) <robh@kernel.org> wrote:
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.example.dtb: power-controller@4b000000 (cortina,gemini-power-controller): '#power-domain-cells' is a required property
> from schema $id: http://devicetree.org/schemas/power/power-domain.yaml
Weird, this power controller does not handle power domains whatsoever,
it handles the mains power. So it should not have any power domain
cells.
Is this the result of some regexp gone stray?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: thermal: lmh: Add SDM670 compatible
From: Richard Acayan @ 2026-03-28 15:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
In-Reply-To: <20260328-resilient-smilodon-of-improvement-a8619f@quoll>
On Sat, Mar 28, 2026 at 01:20:43PM +0100, Krzysztof Kozlowski wrote:
> On Fri, Mar 27, 2026 at 09:40:39PM -0400, Richard Acayan wrote:
> > Document the SDM670 LMh.
> >
> > Signed-off-by: Richard Acayan <mailingradian@gmail.com>
>
> Why are you sending patches already applied 18 days ago?
This one in particular was applied with the assumption that there were
no driver changes to support SDM670, so I re-sent it in case the
different CPU clusters change the suitability of the fallback
compatible.
I'll drop them next time, and patch over this if necessary.
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Rob Herring (Arm) @ 2026-03-28 14:26 UTC (permalink / raw)
To: Khushal Chitturi
Cc: devicetree, linux-kernel, linux-pm, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel, Linus Walleij
In-Reply-To: <20260328124707.141209-1-khushalchitturi@gmail.com>
On Sat, 28 Mar 2026 18:17:07 +0530, Khushal Chitturi wrote:
> Convert the Cortina Systems Gemini Poweroff Controller bindings to
> DT schema.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
> ---
> Note:
> * This patch is part of the GSoC2026 application process for device tree bindings conversions
> * https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>
> .../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
> .../bindings/power/reset/gemini-poweroff.txt | 17 --------
> 2 files changed, 42 insertions(+), 17 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
> delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.example.dtb: power-controller@4b000000 (cortina,gemini-power-controller): '#power-domain-cells' is a required property
from schema $id: http://devicetree.org/schemas/power/power-domain.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260328124707.141209-1-khushalchitturi@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ 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