* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Dmitry Baryshkov @ 2026-03-30 14:04 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Richard Acayan, 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: <1fcecede-16f0-4ce1-b76c-32f569cb5e41@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 03:50:12PM +0200, Konrad Dybcio wrote:
> On 3/30/26 12:59 PM, Dmitry Baryshkov wrote:
> > On Mon, Mar 30, 2026 at 12:32:29PM +0200, Konrad Dybcio wrote:
> >> On 3/29/26 12:44 PM, Dmitry Baryshkov wrote:
> >>> On Fri, Mar 27, 2026 at 09:40:40PM -0400, Richard Acayan wrote:
> >>>> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
> >>>> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
> >>>> the first 6 CPUs are in the little cluster and the next 2 are in the big
> >>>> cluster. Define the clusters in the match data and define the different
> >>>> cluster configuration for SDM670.
> >>>>
> >>>> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
> >>>> the cluster.
> >>>>
> >>>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> >>>> ---
> >>>> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
> >>>> 1 file changed, 56 insertions(+), 13 deletions(-)
> >>>>
> >>>> +static const struct lmh_soc_data sdm670_lmh_data = {
> >>>> + .enable_algos = true,
> >>>> + .node_ids = {
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + },
> >>>> +};
> >>>> +
> >>>> +static const struct lmh_soc_data sdm845_lmh_data = {
> >>>> + .enable_algos = true,
> >>>> + .node_ids = {
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + },
> >>>> +};
> >>>
> >>> These tables made me wonder, can we determine this information from the
> >>> DT? For example, by reading the qcom,freq-domain property. But...
> >>>
> >>>> +
> >>>> +static const struct lmh_soc_data sm8150_lmh_data = {
> >>>> + .enable_algos = false,
> >>>> + .node_ids = {
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + },
> >>>> +};
> >>>
> >>> ... this might be problematic, unless this entry is broken. On SM8150 we
> >>> have three freq domains, but up to now we were programming two clustern
> >>> nodes. Of course it is possible to define that node_id is 0 for freq
> >>> domain 0 and 1 for domains 1 and 2.
> >>
> >> The third cluster situation on 8150 is not super good - we e.g. only have
> >> a single LMH irq that's shared between the big and prime cores. That
> >> was fixed with later SoCs (which is why it's not wired up in the DT today)
> >
> > Thanks!
> >
> > Anyway, from your point of view, would it be better to define mappings
> > in the driver (like it's done with this patch) or parse the DT?
>
> Well, we can spend a lot of time trying to be smart about it and handle
> the odd edge case, or add a simple comparison!
:-)
Then let's go with your suggestion of 'first core from second cluster'.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Konrad Dybcio @ 2026-03-30 13:50 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Richard Acayan, 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: <lnumerwlyvmbdkwum64js46tbnvpxjrdrouhq3vybuwto4st3g@7xzr52e3samd>
On 3/30/26 12:59 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 30, 2026 at 12:32:29PM +0200, Konrad Dybcio wrote:
>> On 3/29/26 12:44 PM, Dmitry Baryshkov wrote:
>>> On Fri, Mar 27, 2026 at 09:40:40PM -0400, Richard Acayan wrote:
>>>> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
>>>> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
>>>> the first 6 CPUs are in the little cluster and the next 2 are in the big
>>>> cluster. Define the clusters in the match data and define the different
>>>> cluster configuration for SDM670.
>>>>
>>>> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
>>>> the cluster.
>>>>
>>>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
>>>> ---
>>>> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
>>>> 1 file changed, 56 insertions(+), 13 deletions(-)
>>>>
>>>> +static const struct lmh_soc_data sdm670_lmh_data = {
>>>> + .enable_algos = true,
>>>> + .node_ids = {
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + },
>>>> +};
>>>> +
>>>> +static const struct lmh_soc_data sdm845_lmh_data = {
>>>> + .enable_algos = true,
>>>> + .node_ids = {
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + },
>>>> +};
>>>
>>> These tables made me wonder, can we determine this information from the
>>> DT? For example, by reading the qcom,freq-domain property. But...
>>>
>>>> +
>>>> +static const struct lmh_soc_data sm8150_lmh_data = {
>>>> + .enable_algos = false,
>>>> + .node_ids = {
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + },
>>>> +};
>>>
>>> ... this might be problematic, unless this entry is broken. On SM8150 we
>>> have three freq domains, but up to now we were programming two clustern
>>> nodes. Of course it is possible to define that node_id is 0 for freq
>>> domain 0 and 1 for domains 1 and 2.
>>
>> The third cluster situation on 8150 is not super good - we e.g. only have
>> a single LMH irq that's shared between the big and prime cores. That
>> was fixed with later SoCs (which is why it's not wired up in the DT today)
>
> Thanks!
>
> Anyway, from your point of view, would it be better to define mappings
> in the driver (like it's done with this patch) or parse the DT?
Well, we can spend a lot of time trying to be smart about it and handle
the odd edge case, or add a simple comparison!
Konrad
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 13:38 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFomzokuF+UL8d0+Syk1FCG3jnUfy7rVr+3iC1GPZmH1UQ@mail.gmail.com>
On 30/03/2026 15:30, Ulf Hansson wrote:
>
> Usually we want bindings to go along with their respective drivers on
> a subsystem basis.
>
> Both patch2 and patch4 updates DT bindings for the power-domain providers.
Patch 2 yes. Patch 4 not. That's why I did not take patch 2.
>
> Why shouldn't the bindings go along with the driver changes here?
Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4
is not pmdomain, so not with pmdomain drivers, so not your tree... At
least I do not see any pmdomain parts in that patch #4. It's a Samsung
SoC PMU driver and none of further driver patches touch that PMU driver.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <a417e45b-1632-4b14-9e3c-f7110db53190@kernel.org>
On Mon, 30 Mar 2026 at 13:24, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 13:12, Ulf Hansson wrote:
> >
> >>
> >>>
> >>> Although, as I said, if you think it's best to funnel them through
> >>> your tree, please do and then share them via an immutable branch, so I
> >>> can apply the pmdomain driver changes.
> >>
> >> soc must go via my tree, but there is no reason to take the pmdomain
> >> binding patch. So I did not take.
> >
> > Yes, they belong to soc/platform, which is common for most
> > power-domain providers.
>
> What does belong to soc/platform? pmdomain changes? No, they do not...
I think you may have misunderstood me here. I was referring to the DT
bindings that describe power domain providers.
Generally speaking, these are often provided via some
SOC/platform-specific hardware (like a PMU for example).
>
> >
> > To allow us to merge/maintain power-domain provider *driver* changes
> > separately, we needed a way to manage the corresponding DT bindings.
>
> Nothing stops that, there is no dependency. For a week I am saying there
> are no dependencies. If there are, please provide any sort of
> argument/proof, otherwise there is nothing to do here.
>
> > That's why I am hosting the immutable "dt" branch for these, which
> > soc/platform maintainers can pull-in when they need it.
> >
> > Of course, doing it the other way around is also possible. Just let me
> > know what you prefer.
>
> Nothing like that is necessary.
Usually we want bindings to go along with their respective drivers on
a subsystem basis.
Both patch2 and patch4 updates DT bindings for the power-domain providers.
Why shouldn't the bindings go along with the driver changes here?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Krzysztof Kozlowski @ 2026-03-30 13:22 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-6-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> opp_data->cpu_dev = get_cpu_device(0);
> if (!opp_data->cpu_dev) {
> @@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
> if (ret)
> goto fail_put_node;
>
> + /* Create device link to k3-socinfo if specified in DT */
> + if (opp_data->soc_data == &am625_soc_data ||
> + opp_data->soc_data == &am62a7_soc_data ||
> + opp_data->soc_data == &am62l3_soc_data ||
> + opp_data->soc_data == &am62p5_soc_data) {
> + struct device_node *socinfo_np;
> +
> + socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
Undocumented ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Krzysztof Kozlowski @ 2026-03-30 13:21 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-4-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> Link CPU OPP table to k3-socinfo driver for dependency tracking.
>
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> index b6e5eee99370..6d1459e9ea71 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> @@ -109,6 +109,7 @@ a53_opp_table: opp-table {
> compatible = "operating-points-v2-ti-cpu";
> opp-shared;
> syscon = <&opp_efuse_table>;
> + ti,soc-info = <&chipid>;
You should have tested this before sending. It obviously fails checks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dikshita Agarwal @ 2026-03-30 13:06 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Ulf Hansson, Rafael J. Wysocki, Bryan O'Donoghue,
Vikash Garodia, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Bryan O'Donoghue, Dikshita Agarwal, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm, linux-media,
Mauro Carvalho Chehab
In-Reply-To: <x5gv6dxdum5klzfjyo7xjqull6o43okkmkn7avssg26epbvrz6@z2brpssbk7iv>
On 3/30/2026 4:45 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
>>
>>
>> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
>>> On SM8250 most of the video clocks are powered by the MMCX domain, while
>>> the PLL is powered on by the MX domain. Extend the driver to support
>>> scaling both power domains, while keeping compatibility with the
>>> existing DTs, which define only the MX domain.
>>>
>>> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
>>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
>>> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
>>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>> index df8e6bf9430e..aa71f7f53ee3 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
>>>
>>> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
>>>
>>> -static const char * const sm8250_opp_pd_table[] = { "mx" };
>>> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
>>>
>>> static const struct platform_clk_data sm8250_clk_table[] = {
>>> {IRIS_AXI_CLK, "iface" },
>>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
>>> index 7b612ad37e4f..74ec81e3d622 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>>> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
>>> return ret;
>>>
>>> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
>>> + /* backwards compatibility for incomplete ABI SM8250 */
>>> + if (ret == -ENODEV &&
>>> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
>>> + iris_opp_pd_data.num_pd_names--;
>>> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
>>> + &core->opp_pmdomain_tbl);
>>> + }
>>> if (ret < 0)
>>> return ret;
>>>
>>>
>>
>> Hitting below compilation error on latest kernel
>>
>> drivers/media/platform/qcom/iris/iris_probe.c: In function
>> ‘iris_init_power_domains’:
>> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
>> read-only member ‘num_pd_names’
>> 71 | iris_opp_pd_data.num_pd_names--;
>
> See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
> dev_pm_domain_attach_data")
Ack, Thanks!
Regards,
Dikshita
>
>>
>> Could you please check and fix.
>>
>> Thanks,
>> Dikshita
>
^ permalink raw reply
* Re: [PATCH v8 2/2] cpufreq: Add boost_freq_req QoS request
From: Zhongqiu Han @ 2026-03-30 13:01 UTC (permalink / raw)
To: zhenglifeng (A), Pierre Gondois, linux-kernel
Cc: Huang Rui, Gautham R. Shenoy, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Viresh Kumar, linux-pm, zhongqiu.han
In-Reply-To: <6cd973e4-5df5-47b0-86d5-1552f8ba8d2e@huawei.com>
On 3/30/2026 3:16 PM, zhenglifeng (A) wrote:
> On 3/30/2026 12:00 PM, Zhongqiu Han wrote:
>> On 3/30/2026 10:10 AM, zhenglifeng (A) wrote:
>>> On 3/29/2026 5:00 PM, Zhongqiu Han wrote:
>>>>> @@ -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.
>>>>
>>>
>>> Good catch!
>>>
>>> How about remove the kfree() here and just leave it to
>>> cpufreq_policy_free()?
>>>
>>
>> Thanks for the suggestion — this is another fix approach we can
>> explore, but there seems to be a small caveat.
>>
>> Some additional changes would still be needed; otherwise, removing the
>> kfree() here and deferring it to cpufreq_policy_free() can lead to a
>> warning.
>>
>> The reason is that we neither free policy->min_freq_req nor set policy
>> ->min_freq_req = NULL. As a result, when cpufreq_policy_free() later
>> calls freq_qos_remove_request(policy->min_freq_req), it hits the
>> following warning:
>>
>> if (WARN(!freq_qos_request_active(req),
>> "%s() called for unknown object\n", __func__))
>> return -EINVAL;
>>
>
> Therefore, it seems the only option is to allocate memory separately for
> boost_freq_req.
>
Thanks Lifeng. Allocating memory separately could also be a direction we
can explore. I also sketched another small example in a separate mail
thread for discussion.
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v8 2/2] cpufreq: Add boost_freq_req QoS request
From: Zhongqiu Han @ 2026-03-30 12:55 UTC (permalink / raw)
To: Viresh Kumar
Cc: Pierre Gondois, linux-kernel, Lifeng Zheng, Huang Rui,
Gautham R. Shenoy, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, linux-pm, zhongqiu.han
In-Reply-To: <5syn6lnv4vfd3gapmlczkpkfob4oxrvfu3sozet2fog22mj5mw@mfyspzeruph6>
On 3/30/2026 1:20 PM, Viresh Kumar wrote:
> On 29-03-26, 17:00, Zhongqiu Han wrote:
>> 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.
>
> Nice catch.
>
> The right solution to this I guess is to do kfree and setting min_freq_req to
> NULL if boost_freq_req fails (just like what happens in min_freq_req failure
> now) and then for later failures, don't do kfree at all but just set the failed
> qos feature to NULL (like what is done for max_freq_req now).
>
Thanks Viresh — agreed, that approach makes sense.
I sketched a small example along those lines for discussion only if
needed: add boost_freq_req early when boost_supported, free the shared
allocation if that add fails, and on later failures just unwind without
freeing the block.
+ 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;
+ kfree(policy->min_freq_req);
+ policy->min_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.
- */
+ 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;
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: Krzysztof Kozlowski @ 2026-03-30 12:10 UTC (permalink / raw)
To: André Draszik, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <dcf2c447d9bbe16e800a4dd7e74ecc26d3ade3db.camel@linaro.org>
On 30/03/2026 14:00, André Draszik wrote:
> On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>>
>> This causes warnings, so I dropped the patches.
>
> I assume warnings are because I didn't make it clear enough that patch
> 2 is actually required?
No, these are obvious errors coming from bindings. You can try yourself
instead of asking maintainer to run the commands for you...
>
>> I really do not
>> understand how this is organized. This is not a dependency for pm
>> domains driver but it is included here.
>
> The binding is being updated, and the driver follows suit.
> I particular, the driver needs to be aware that pd is (can be) a child
> of pmu.
>
> Yes, the driver does not depend on this binding update, but it shows what
> the driver must support. I believe this is what we have done in the past:
> binding and driver updates in same series.
Yes, foo-binding goes with foo-driver to foo-subsystem. It does not mean
you put here completely different bindings. Why? Because just like foo
goes to foo-subsystem, then bar-binding goes with bar-driver to
bar-subsystem.
>
> I could move patches 3 and 4 from this series together with a DTS
> update patch into a separate series, if that would be deemed a better
> approach?
I asked you what are the dependencies and you answer there are some but
you can move it outside of patchset. So are there or are there not
dependencies? If there are, then you cannot move out. But then I ask
what are the dependencies.
It feels like question to trick the maintainer. Maintainer complained,
so you propose whatever he objected to without understanding whether
this is correct or not correct approach.
>
>> It is a soft dependency for DTS,
>> but that is nowhere to be found.
>
> I was waiting for review of all binding changes before posting DTS.
That would be fine explanation, if you also read maintainer soc profile
for Samsung and try what is written there. You would see that you
introduced new warnings without any fix possible as far as next is
concerned.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [linux-next:master] [powercap] 42dde4365f: WARNING:possible_circular_locking_dependency_detected
From: Rafael J. Wysocki @ 2026-03-30 12:06 UTC (permalink / raw)
To: kernel test robot, Kuppuswamy Sathyanarayanan
Cc: oe-lkp, lkp, Rafael J. Wysocki, Zhang Rui, Srinivas Pandruvada,
linux-pm
In-Reply-To: <202603300921.b5dc709c-lkp@intel.com>
Hi,
On Mon, Mar 30, 2026 at 9:52 AM kernel test robot <oliver.sang@intel.com> wrote:
>
>
>
> Hello,
>
> kernel test robot noticed "WARNING:possible_circular_locking_dependency_detected" on:
>
> commit: 42dde4365f89dce91bdc07fd1bca047d71dd162e ("powercap: intel_rapl: Register PM notifier only when RAPL package exists")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> [test failed on linux-next/master 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c]
>
> in testcase: kernel-selftests
> version: kernel-selftests-x86_64-9f2693489ef8-1_20260201
> with following parameters:
>
> group: breakpoints
>
>
>
> config: x86_64-rhel-9.4-kselftests
> compiler: gcc-14
> test machine: 16 threads Intel(R) Core(TM) i7-13620H (Raptor Lake) with 32G memory
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
> 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 <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202603300921.b5dc709c-lkp@intel.com
>
>
>
> kern :warn : [ 74.925211] [ T2261] WARNING: possible circular locking dependency detected
> kern :warn : [ 74.925213] [ T2261] 7.0.0-rc2-00011-g42dde4365f89 #1 Tainted: G S W
> kern :err : [ 74.937766] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ba000-0x3f7bafff], got write-back
> kern :warn : [ 74.939962] [ T2261] ------------------------------------------------------
> kern :warn : [ 74.939963] [ T2261] sh/2261 is trying to acquire lock:
> kern :warn : [ 74.939964] [ T2261] ffffffff8557ed28
> kern :err : [ 74.952510] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7b9000-0x3f7b9fff], got write-back
> kern :warn : [ 74.959121] [ T2261] (cpu_add_remove_lock){+.+.}-{4:4}, at: cpu_hotplug_pm_callback (kernel/cpu.c:571 kernel/cpu.c:2011)
> kern :err : [ 74.971676] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7af000-0x3f7affff], got write-back
> kern :warn : [ 74.973877] [ T2261]
> but task is already holding lock:
> kern :warn : [ 74.973878] [ T2261] ffffffff85605e30 ((pm_chain_head).rwsem
> kern :err : [ 74.986428] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ad000-0x3f7adfff], got write-back
> kern :warn : [ 74.990882] [ T2261] ){++++}-{4:4}, at: blocking_notifier_call_chain_robust (kernel/notifier.c:120 kernel/notifier.c:345 kernel/notifier.c:333)
> kern :err : [ 75.003437] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f8e5000-0x3f8e5fff], got write-back
> kern :warn : [ 75.008321] [ T2261]
> which lock already depends on the new lock.
>
> kern :warn : [ 75.008322] [ T2261]
> the existing dependency chain (in reverse order) is:
> kern :warn : [ 75.008322] [ T2261]
> -> #3
> user :notice: [ 75.017865] [ T418] Created symlink '/etc/systemd/system/sockets.target.wants/uuidd.socket' → '/usr/lib/systemd/system/uuidd.socket'.
>
> user :notice: [ 75.018570] [ T418] /usr/sbin/policy-rc.d returned 101, not running 'start uuidd.service uuidd.socket'
>
> kern :err : [ 75.020879] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ac000-0x3f7acfff], got write-back
> kern :warn : [ 75.023062] [ T2261] ((pm_chain_head).rwsem){++++}-{4:4}
> kern :err : [ 75.035631] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ab000-0x3f7abfff], got write-back
> kern :warn : [ 75.042492] [ T2261] :
> kern :warn : [ 75.042494] [ T2261] __lock_acquire (kernel/locking/lockdep.c:5237 (discriminator 1))
> kern :err : [ 75.053565] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f880000-0x3f880fff], got write-back
> kern :warn : [ 75.057172] [ T2261] lock_acquire (include/trace/events/lock.h:24 (discriminator 15) include/trace/events/lock.h:24 (discriminator 15) kernel/locking/lockdep.c:5831 (discriminator 15))
> kern :err : [ 75.069731] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f881000-0x3f881fff], got write-back
> kern :warn : [ 75.076607] [ T2261] down_write (arch/x86/include/asm/preempt.h:80 (discriminator 10) kernel/locking/rwsem.c:1315 (discriminator 10) kernel/locking/rwsem.c:1326 (discriminator 10) kernel/locking/rwsem.c:1591 (discriminator 10))
> kern :err : [ 75.081798] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d8000-0x3f7d8fff], got write-back
> kern :warn : [ 75.085380] [ T2261] blocking_notifier_chain_register (kernel/notifier.c:264 kernel/notifier.c:282)
> kern :err : [ 75.097937] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d7000-0x3f7d7fff], got write-back
> kern :warn : [ 75.106461] [ T2261] rapl_add_package_cpuslocked (drivers/powercap/intel_rapl_common.c:2267) intel_rapl_common
> kern :err : [ 75.119046] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d1000-0x3f7d1fff], got write-back
> kern :warn : [ 75.126242] [ T2261] rapl_cpu_online (drivers/powercap/intel_rapl_msr.c:81) intel_rapl_msr
> kern :err : [ 75.131871] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ce000-0x3f7cefff], got write-back
> kern :warn : [ 75.144377] [ T2261] cpuhp_invoke_callback (kernel/cpu.c:194)
> kern :err : [ 75.152251] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ca000-0x3f7cafff], got write-back
> kern :warn : [ 75.164759] [ T2261] cpuhp_thread_fun (kernel/cpu.c:1109 (discriminator 1))
> kern :warn : [ 75.164762] [ T2261] smpboot_thread_fn (kernel/smpboot.c:160)
> kern :err : [ 75.175063] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7bc000-0x3f7bcfff], got write-back
> kern :warn : [ 75.183928] [ T2261] kthread (kernel/kthread.c:467)
> kern :err : [ 75.188770] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7bb000-0x3f7bbfff], got write-back
> kern :warn : [ 75.200932] [ T2261] ret_from_fork (arch/x86/kernel/process.c:164)
> kern :err : [ 75.203171] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ba000-0x3f7bafff], got write-back
> kern :warn : [ 75.212468] [ T2261] ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
> kern :err : [ 75.214715] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7b9000-0x3f7b9fff], got write-back
> kern :warn : [ 75.227219] [ T2261]
> -> #2 (cpuhp_state-up){+.+.}-{0:0}
> kern :err : [ 75.232580] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7af000-0x3f7affff], got write-back
> kern :warn : [ 75.245099] [ T2261] :
> kern :warn : [ 75.245100] [ T2261] __lock_acquire (kernel/locking/lockdep.c:5237 (discriminator 1))
> kern :err : [ 75.247416] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ad000-0x3f7adfff], got write-back
> kern :warn : [ 75.252473] [ T2261] lock_acquire (include/trace/events/lock.h:24 (discriminator 15) include/trace/events/lock.h:24 (discriminator 15) kernel/locking/lockdep.c:5831 (discriminator 15))
> kern :warn : [ 75.252475] [ T2261] cpuhp_thread_fun (kernel/cpu.c:1088)
> kern :err : [ 75.265022] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f8e5000-0x3f8e5fff], got write-back
> kern :warn : [ 75.270422] [ T2261] smpboot_thread_fn (kernel/smpboot.c:160)
> kern :warn : [ 75.270424] [ T2261] kthread (kernel/kthread.c:467)
> kern :err : [ 75.282979] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ac000-0x3f7acfff], got write-back
> kern :warn : [ 75.287599] [ T2261] ret_from_fork (arch/x86/kernel/process.c:164)
> kern :warn : [ 75.287602] [ T2261] ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
> kern :err : [ 75.300163] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ab000-0x3f7abfff], got write-back
> kern :warn : [ 75.306600] [ T2261]
> -> #1 (cpu_hotplug_lock){++++}-{0:0}
> kern :err : [ 75.319409] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x4035f000-0x40360fff], got write-back
> kern :warn : [ 75.327073] [ T2261] :
> kern :warn : [ 75.327074] [ T2261] __lock_acquire (kernel/locking/lockdep.c:5237 (discriminator 1))
> kern :warn : [ 75.327077] [ T2261] lock_acquire (include/trace/events/lock.h:24 (discriminator 15) include/trace/events/lock.h:24 (discriminator 15) kernel/locking/lockdep.c:5831 (discriminator 15))
> kern :err : [ 75.343199] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f880000-0x3f880fff], got write-back
> kern :warn : [ 75.346150] [ T2261] percpu_down_write (kernel/locking/percpu-rwsem.c:235)
> kern :err : [ 75.358708] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f881000-0x3f881fff], got write-back
> kern :warn : [ 75.364461] [ T2261] _cpu_up (include/asm-generic/bitops/instrumented-non-atomic.h:141 include/linux/cpumask.h:649 include/linux/cpumask.h:1246 kernel/cpu.c:1624)
> kern :warn : [ 75.364462] [ T2261] cpu_up (kernel/cpu.c:1706)
> kern :warn : [ 75.364464] [ T2261] cpuhp_bringup_mask (kernel/cpu.c:1772 (discriminator 1))
> kern :err : [ 75.377019] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d8000-0x3f7d8fff], got write-back
> kern :warn : [ 75.382247] [ T2261] bringup_nonboot_cpus (kernel/cpu.c:1851 kernel/cpu.c:1876)
> kern :err : [ 75.387605] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d7000-0x3f7d7fff], got write-back
> kern :warn : [ 75.400124] [ T2261] smp_init (include/linux/bitmap.h:461 include/linux/nodemask.h:244 include/linux/nodemask.h:424 kernel/smp.c:1003)
> kern :err : [ 75.404613] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d1000-0x3f7d1fff], got write-back
> kern :warn : [ 75.417126] [ T2261] kernel_init_freeable (init/main.c:1685)
> kern :err : [ 75.422136] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ce000-0x3f7cefff], got write-back
> kern :warn : [ 75.434649] [ T2261] kernel_init (init/main.c:1584)
> kern :warn : [ 75.434652] [ T2261] ret_from_fork (arch/x86/kernel/process.c:164)
> kern :err : [ 75.439834] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ca000-0x3f7cafff], got write-back
> kern :warn : [ 75.452350] [ T2261] ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
> kern :warn : [ 75.452352] [ T2261]
> -> #0 (
> user :err : [ 75.458360] [ T420] error: dpkg -i /opt/deb/python3_3.13.5-1_amd64.deb failed.
>
> kern :err : [ 75.459704] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7bc000-0x3f7bcfff], got write-back
> kern :warn : [ 75.472214] [ T2261] cpu_add_remove_lock){+.+.}-{4:4}:
> kern :warn : [ 75.472217] [ T2261] check_prev_add (kernel/locking/lockdep.c:3166 (discriminator 2))
> kern :err : [ 75.474541] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7bb000-0x3f7bbfff], got write-back
> kern :warn : [ 75.479596] [ T2261] validate_chain (kernel/locking/lockdep.c:3285 kernel/locking/lockdep.c:3908)
> kern :warn : [ 75.479598] [ T2261] __lock_acquire (kernel/locking/lockdep.c:5237 (discriminator 1))
> kern :err : [ 75.492148] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ba000-0x3f7bafff], got write-back
> kern :warn : [ 75.497554] [ T2261] lock_acquire (include/trace/events/lock.h:24 (discriminator 15) include/trace/events/lock.h:24 (discriminator 15) kernel/locking/lockdep.c:5831 (discriminator 15))
> kern :warn : [ 75.497556] [ T2261] __mutex_lock (arch/x86/include/asm/jump_label.h:37 include/trace/events/lock.h:95 kernel/locking/mutex.c:616 kernel/locking/mutex.c:776)
> kern :err : [ 75.502747] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7b9000-0x3f7b9fff], got write-back
> kern :warn : [ 75.515254] [ T2261] cpu_hotplug_pm_callback (kernel/cpu.c:571 kernel/cpu.c:2011)
> kern :err : [ 75.520613] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7af000-0x3f7affff], got write-back
> kern :warn : [ 75.525062] [ T2261] notifier_call_chain (kernel/notifier.c:87)
> kern :err : [ 75.537613] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ad000-0x3f7adfff], got write-back
> kern :warn : [ 75.542580] [ T2261] blocking_notifier_call_chain_robust (kernel/notifier.c:121 kernel/notifier.c:345 kernel/notifier.c:333)
> kern :warn : [ 75.542583] [ T2261] pm_notifier_call_chain_robust (include/linux/notifier.h:207 kernel/power/main.c:174)
> kern :err : [ 75.547762] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f8e5000-0x3f8e5fff], got write-back
> kern :warn : [ 75.560278] [ T2261] enter_state (kernel/power/suspend.c:381 kernel/power/suspend.c:609)
> kern :warn : [ 75.560281] [ T2261] pm_suspend (kernel/power/suspend.c:645 kernel/power/suspend.c:636)
> kern :err : [ 75.567809] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ac000-0x3f7acfff], got write-back
> kern :warn : [ 75.580320] [ T2261] state_store (kernel/power/main.c:828 (discriminator 1))
> kern :warn : [ 75.580322] [ T2261] kernfs_fop_write_iter (fs/kernfs/file.c:88 fs/kernfs/file.c:356)
> kern :err : [ 75.582645] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ab000-0x3f7abfff], got write-back
> kern :warn : [ 75.587701] [ T2261] vfs_write (fs/read_write.c:596 (discriminator 1) fs/read_write.c:688 (discriminator 1))
> kern :warn : [ 75.587703] [ T2261] ksys_write (fs/read_write.c:740)
> kern :err : [ 75.595073] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f880000-0x3f880fff], got write-back
> kern :warn : [ 75.605660] [ T2261] do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
> kern :err : [ 75.610934] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f881000-0x3f881fff], got write-back
> kern :warn : [ 75.623438] [ T2261] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> kern :warn : [ 75.623441] [ T2261]
> other info that might help us debug this:
>
> kern :err : [ 75.627851] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d8000-0x3f7d8fff], got write-back
> kern :warn : [ 75.632216] [ T2261] Chain exists of:
> cpu_add_remove_lock -->
> kern :err : [ 75.637575] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d7000-0x3f7d7fff], got write-back
> kern :warn : [ 75.650084] [ T2261] cpuhp_state-up --> (pm_chain_head).rwsem
> kern :err : [ 75.655616] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7d1000-0x3f7d1fff], got write-back
> kern :warn : [ 75.668127] [ T2261]
>
> kern :warn : [ 75.668127] [ T2261] Possible unsafe locking scenario:
>
> kern :warn : [ 75.668128] [ T2261] CPU0 CPU1
> kern :warn : [ 75.668129] [ T2261] ---- ----
> kern :warn : [ 75.668130] [ T2261] rlock(
> kern :err : [ 75.672531] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ce000-0x3f7cefff], got write-back
> kern :warn : [ 75.685039] [ T2261] (pm_chain_head).rwsem);
> kern :warn : [ 75.685041] [ T2261] lock(cpuhp_state-up
> kern :err : [ 75.690656] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7ca000-0x3f7cafff], got write-back
> kern :warn : [ 75.703171] [ T2261] );
> kern :warn : [ 75.703172] [ T2261] lock((pm_chain_head).rwsem);
> kern :err : [ 75.707918] [ T2140] x86/PAT: bmc-watchdog:2140 map pfn expected mapping type uncached-minus for [mem 0x3f7bc000-0x3f7bcfff], got write-back
> kern :warn : [ 75.712887] [ T2261] lock(cpu_add_remove_lock);
> kern :warn : [ 75.712889] [ T2261]
> *** DEADLOCK ***
>
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260330/202603300921.b5dc709c-lkp@intel.com
The report is correct.
rapl_pm_notifier cannot be registered with CPUs locked because CPU
hotplug has its own PM notifier which locks CPUs under
(pm_chain_head).rwsem.
I'm dropping commit 42dde4365f89 ("powercap: intel_rapl: Register PM
notifier only when RAPL package exists") along all of the commits that
depend on it from my linux-next branch.
Thanks!
^ permalink raw reply
* [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Create explicit device link when OPP table has ti,soc-info property.
Prevents unbinding k3-socinfo while ti-cpufreq is using it.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 48 ++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 88f7912ef6a8..60c34b0da0c5 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
#include <linux/regmap.h>
@@ -111,6 +112,7 @@ struct ti_cpufreq_data {
struct device_node *opp_node;
struct regmap *syscon;
const struct ti_cpufreq_soc_data *soc_data;
+ struct device_link *soc_link;
};
static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
@@ -542,6 +544,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return -ENOMEM;
opp_data->soc_data = match->data;
+ platform_set_drvdata(pdev, opp_data);
opp_data->cpu_dev = get_cpu_device(0);
if (!opp_data->cpu_dev) {
@@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (ret)
goto fail_put_node;
+ /* Create device link to k3-socinfo if specified in DT */
+ if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ struct device_node *socinfo_np;
+
+ socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
+ if (socinfo_np) {
+ struct platform_device *socinfo_pdev;
+ struct device_link *link;
+
+ socinfo_pdev = of_find_device_by_node(socinfo_np);
+ of_node_put(socinfo_np);
+
+ if (!socinfo_pdev) {
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ if (!socinfo_pdev->dev.driver) {
+ put_device(&socinfo_pdev->dev);
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ link = device_link_add(opp_data->cpu_dev,
+ &socinfo_pdev->dev,
+ DL_FLAG_STATELESS);
+ if (link)
+ opp_data->soc_link = link;
+
+ put_device(&socinfo_pdev->dev);
+ }
+ }
+
/*
* OPPs determine whether or not they are supported based on
* two metrics:
@@ -600,6 +639,14 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return ret;
}
+static void ti_cpufreq_remove(struct platform_device *pdev)
+{
+ struct ti_cpufreq_data *opp_data = platform_get_drvdata(pdev);
+
+ if (opp_data && opp_data->soc_link)
+ device_link_del(opp_data->soc_link);
+}
+
static int __init ti_cpufreq_init(void)
{
const struct of_device_id *match;
@@ -616,6 +663,7 @@ module_init(ti_cpufreq_init);
static struct platform_driver ti_cpufreq_driver = {
.probe = ti_cpufreq_probe,
+ .remove = ti_cpufreq_remove,
.driver = {
.name = "ti-cpufreq",
},
--
2.34.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
index 8982a7b9f1a6..1a498c5eb3d1 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
@@ -108,6 +108,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
index b6e5eee99370..6d1459e9ea71 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
index c249883a8a8d..b0020e667882 100644
--- a/arch/arm64/boot/dts/ti/k3-am625.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/5] cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Defer probe when k3-socinfo hasn't registered the SoC device yet.
Fixes incorrect revision detection when ti-cpufreq probes first.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 3d1129aeed02..88f7912ef6a8 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -441,6 +441,15 @@ static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
*/
*revision_value = 0x1;
goto done;
+ } else if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ /*
+ * For K3 SoCs, if soc_device_match fails, socinfo hasn't
+ * probed yet. Defer probe to wait for it.
+ */
+ return -EPROBE_DEFER;
}
ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
--
2.34.1
^ permalink raw reply related
* [PATCH 0/5] cpufreq: ti: Fix probe ordering and add device link support for K3 SoCs
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
For K3 SoCs, ti-cpufreq depends on k3-socinfo to provide SoC revision
information via soc_device_match(). If ti-cpufreq probes before
k3-socinfo, soc_device_match() returns NULL, causing incorrect
revision detection and OPP table initialization failures.
Add EPROBE_DEFER handling in ti-cpufreq when soc_device_match() fails
for K3 SoCs, ensuring k3-socinfo probes first.
Add device link support via a new DT property "ti,soc-info" in CPU
OPP tables. Device links prevent unbinding k3-socinfo while
ti-cpufreq is using it.
EPROBE_DEFER handles first-boot probe ordering, while device links
provide runtime dependency management.
For backward compatibility, the DT property is optional.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
Akashdeep Kaur (5):
cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
cpufreq: ti: Add device link to k3-socinfo
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
drivers/cpufreq/ti-cpufreq.c | 57 +++++++++++++++++++++++++++
4 files changed, 60 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: André Draszik @ 2026-03-30 12:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <355b2f8f-0a3e-4209-8b1e-10600c2b3df9@kernel.org>
On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>
> This causes warnings, so I dropped the patches.
I assume warnings are because I didn't make it clear enough that patch
2 is actually required?
> I really do not
> understand how this is organized. This is not a dependency for pm
> domains driver but it is included here.
The binding is being updated, and the driver follows suit.
I particular, the driver needs to be aware that pd is (can be) a child
of pmu.
Yes, the driver does not depend on this binding update, but it shows what
the driver must support. I believe this is what we have done in the past:
binding and driver updates in same series.
I could move patches 3 and 4 from this series together with a DTS
update patch into a separate series, if that would be deemed a better
approach?
> It is a soft dependency for DTS,
> but that is nowhere to be found.
I was waiting for review of all binding changes before posting DTS.
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH v2] thermal: core: Address thermal zone removal races with resume
From: Rafael J. Wysocki @ 2026-03-30 11:41 UTC (permalink / raw)
To: Lukasz Luba
Cc: Rafael J. Wysocki, Mauricio Faria de Oliveira, Daniel Lezcano,
LKML, Linux PM
In-Reply-To: <5321acf9-0de4-4b8a-811d-e1d71b152887@arm.com>
On Mon, Mar 30, 2026 at 11:14 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
>
>
> On 3/27/26 09:49, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Since thermal_zone_pm_complete() and thermal_zone_device_resume()
> > re-initialize the poll_queue delayed work for the given thermal zone,
> > the cancel_delayed_work_sync() in thermal_zone_device_unregister()
> > may miss some already running work items and the thermal zone may
> > be freed prematurely [1].
> >
> > There are two failing scenarios that both start with
> > running thermal_pm_notify_complete() right before invoking
> > thermal_zone_device_unregister() for one of the thermal zones.
> >
> > In the first scenario, there is a work item already running for
> > the given thermal zone when thermal_pm_notify_complete() calls
> > thermal_zone_pm_complete() for that thermal zone and it continues to
> > run when thermal_zone_device_unregister() starts. Since the poll_queue
> > delayed work has been re-initialized by thermal_pm_notify_complete(), the
> > running work item will be missed by the cancel_delayed_work_sync() in
> > thermal_zone_device_unregister() and if it continues to run past the
> > freeing of the thermal zone object, a use-after-free will occur.
> >
> > In the second scenario, thermal_zone_device_resume() queued up by
> > thermal_pm_notify_complete() runs right after the thermal_zone_exit()
> > called by thermal_zone_device_unregister() has returned. The poll_queue
> > delayed work is re-initialized by it before cancel_delayed_work_sync() is
> > called by thermal_zone_device_unregister(), so it may continue to run
> > after the freeing of the thermal zone object, which also leads to a
> > use-after-free.
> >
> > Address the first failing scenario by ensuring that no thermal work
> > items will be running when thermal_pm_notify_complete() is called.
> > For this purpose, first move the cancel_delayed_work() call from
> > thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent
> > new work from entering the workqueue going forward. Next, switch
> > over to using a dedicated workqueue for thermal events and update
> > the code in thermal_pm_notify() to flush that workqueue after
> > thermal_pm_notify_prepare() has returned which will take care of
> > all leftover thermal work already on the workqueue (that leftover
> > work would do nothing useful anyway because all of the thermal zones
> > have been flagged as suspended).
> >
> > The second failing scenario is addressed by adding a tz->state check
> > to thermal_zone_device_resume() to prevent it from re-initializing
> > the poll_queue delayed work if the thermal zone is going away.
> >
> > Note that the above changes will also facilitate relocating the suspend
> > and resume of thermal zones closer to the suspend and resume of devices,
> > respectively.
> >
> > Fixes: 5a5efdaffda5 ("thermal: core: Resume thermal zones asynchronously")
> > Reported-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> > Closes: https://lore.kernel.org/linux-pm/20260324-thermal-core-uaf-init_delayed_work-v1-1-6611ae76a8a1@igalia.com/ [1]
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >
> > v1 -> v2: Return -ENOMEM from thermal_init() when the workqueue allocation
> > fails (Sashiko)
> >
> > Lukasz, Daniel, I'm quite confident about this patch, but I would appreciate
> > your feedback.
>
> My apologies for delay...
>
> >
> > ---
> > drivers/thermal/thermal_core.c | 31 ++++++++++++++++++++++++++-----
> > 1 file changed, 26 insertions(+), 5 deletions(-)
> >
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -42,6 +42,8 @@ static struct thermal_governor *def_gove
> >
> > static bool thermal_pm_suspended;
> >
> > +static struct workqueue_struct *thermal_wq __ro_after_init;
> > +
> > /*
> > * Governor section: set of functions to handle thermal governors
> > *
> > @@ -314,7 +316,7 @@ static void thermal_zone_device_set_poll
> > if (delay > HZ)
> > delay = round_jiffies_relative(delay);
> >
> > - mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, delay);
> > + mod_delayed_work(thermal_wq, &tz->poll_queue, delay);
> > }
> >
> > static void thermal_zone_recheck(struct thermal_zone_device *tz, int error)
> > @@ -1795,6 +1797,10 @@ static void thermal_zone_device_resume(s
> >
> > guard(thermal_zone)(tz);
> >
> > + /* If the thermal zone is going away, there's nothing to do. */
> > + if (tz->state & TZ_STATE_FLAG_EXIT)
> > + return;
> > +
> > tz->state &= ~(TZ_STATE_FLAG_SUSPENDED | TZ_STATE_FLAG_RESUMING);
> >
> > thermal_debug_tz_resume(tz);
> > @@ -1825,6 +1831,9 @@ static void thermal_zone_pm_prepare(stru
> > }
> >
> > tz->state |= TZ_STATE_FLAG_SUSPENDED;
> > +
> > + /* Prevent new work from getting to the workqueue subsequently. */
> > + cancel_delayed_work(&tz->poll_queue);
> > }
> >
> > static void thermal_pm_notify_prepare(void)
> > @@ -1843,8 +1852,6 @@ static void thermal_zone_pm_complete(str
> > {
> > guard(thermal_zone)(tz);
> >
> > - cancel_delayed_work(&tz->poll_queue);
> > -
> > reinit_completion(&tz->resume);
> > tz->state |= TZ_STATE_FLAG_RESUMING;
> >
> > @@ -1854,7 +1861,7 @@ static void thermal_zone_pm_complete(str
> > */
> > INIT_DELAYED_WORK(&tz->poll_queue, thermal_zone_device_resume);
> > /* Queue up the work without a delay. */
> > - mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, 0);
> > + mod_delayed_work(thermal_wq, &tz->poll_queue, 0);
> > }
> >
> > static void thermal_pm_notify_complete(void)
> > @@ -1877,6 +1884,11 @@ static int thermal_pm_notify(struct noti
> > case PM_RESTORE_PREPARE:
> > case PM_SUSPEND_PREPARE:
> > thermal_pm_notify_prepare();
> > + /*
> > + * Allow any leftover thermal work items already on the
> > + * worqueue to complete so they don't get in the way later.
> > + */
> > + flush_workqueue(thermal_wq);
> > break;
> > case PM_POST_HIBERNATION:
> > case PM_POST_RESTORE:
> > @@ -1909,9 +1921,16 @@ static int __init thermal_init(void)
> > if (result)
> > goto error;
> >
> > + thermal_wq = alloc_workqueue("thermal_events",
> > + WQ_FREEZABLE | WQ_POWER_EFFICIENT | WQ_PERCPU, 0);
>
>
> Why we need those workqueue instances per-cpu?
That's to limit the changes in this fix to what's needed to address
the problem at hand.
The previously used workqueue was also per-CPU and freezable.
> It isn't a concurrent work, only one CPU can manage the cpufreq domain.
>
> I would drop that flag and allow to have single instance and migrate
> between cpus (to not wake up the one which queued the work).
I have a separate patch for that on top of this one, will post it later.
Let's avoid mixing fixes with changes that aren't directly related to them.
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 11:24 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFpOPC2stAJ262jdap-=ByY09AeQ0kj6p_9FTGJBx+Tu-Q@mail.gmail.com>
On 30/03/2026 13:12, Ulf Hansson wrote:
>
>>
>>>
>>> Although, as I said, if you think it's best to funnel them through
>>> your tree, please do and then share them via an immutable branch, so I
>>> can apply the pmdomain driver changes.
>>
>> soc must go via my tree, but there is no reason to take the pmdomain
>> binding patch. So I did not take.
>
> Yes, they belong to soc/platform, which is common for most
> power-domain providers.
What does belong to soc/platform? pmdomain changes? No, they do not...
>
> To allow us to merge/maintain power-domain provider *driver* changes
> separately, we needed a way to manage the corresponding DT bindings.
Nothing stops that, there is no dependency. For a week I am saying there
are no dependencies. If there are, please provide any sort of
argument/proof, otherwise there is nothing to do here.
> That's why I am hosting the immutable "dt" branch for these, which
> soc/platform maintainers can pull-in when they need it.
>
> Of course, doing it the other way around is also possible. Just let me
> know what you prefer.
Nothing like that is necessary.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dmitry Baryshkov @ 2026-03-30 11:15 UTC (permalink / raw)
To: Dikshita Agarwal
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Ulf Hansson, Rafael J. Wysocki, Bryan O'Donoghue,
Vikash Garodia, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Bryan O'Donoghue, Dikshita Agarwal, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm, linux-media,
Mauro Carvalho Chehab
In-Reply-To: <5e2635ac-35de-645b-b5e7-235923f844ce@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
>
>
> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
> > On SM8250 most of the video clocks are powered by the MMCX domain, while
> > the PLL is powered on by the MX domain. Extend the driver to support
> > scaling both power domains, while keeping compatibility with the
> > existing DTs, which define only the MX domain.
> >
> > Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
> > Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> > drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
> > drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > index df8e6bf9430e..aa71f7f53ee3 100644
> > --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
> >
> > static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
> >
> > -static const char * const sm8250_opp_pd_table[] = { "mx" };
> > +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
> >
> > static const struct platform_clk_data sm8250_clk_table[] = {
> > {IRIS_AXI_CLK, "iface" },
> > diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> > index 7b612ad37e4f..74ec81e3d622 100644
> > --- a/drivers/media/platform/qcom/iris/iris_probe.c
> > +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> > @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
> > return ret;
> >
> > ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
> > + /* backwards compatibility for incomplete ABI SM8250 */
> > + if (ret == -ENODEV &&
> > + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
> > + iris_opp_pd_data.num_pd_names--;
> > + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
> > + &core->opp_pmdomain_tbl);
> > + }
> > if (ret < 0)
> > return ret;
> >
> >
>
> Hitting below compilation error on latest kernel
>
> drivers/media/platform/qcom/iris/iris_probe.c: In function
> ‘iris_init_power_domains’:
> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
> read-only member ‘num_pd_names’
> 71 | iris_opp_pd_data.num_pd_names--;
See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
dev_pm_domain_attach_data")
>
> Could you please check and fix.
>
> Thanks,
> Dikshita
--
With best wishes
Dmitry
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <3bb6b71e-947b-4248-95ba-79852f743c1d@kernel.org>
On Mon, 30 Mar 2026 at 12:17, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 12:13, Ulf Hansson wrote:
> > On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 23/03/2026 12:13, Ulf Hansson wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>
> >>>>
> >>>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> >>>>> This series adds support for the power domains on Google GS101.
> >>>>>
> >>>>> There are a few differences compared to SoCs already supported by this
> >>>>> driver:
> >>>>> * register access does not work via plain ioremap() / readl() /
> >>>>> writel().
> >>>>> Instead, the regmap created by the PMU driver must be used (which
> >>>>> uses Arm SMCC calls under the hood).
> >>>>> * DTZPC: a call needs to be made before and after power domain off/on,
> >>>>> to inform the EL3 firmware of the request.
> >>>>> * power domains can and are fed by a regulator rail and therefore
> >>>>> regulator control needed be implemented.
> >>>>>
> >>>>> [...]
> >>>>
> >>>> Applied, thanks!
> >>>>
> >>>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
> >>>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
> >>>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
> >>>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
> >>>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
> >>>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
> >>>>
> >>>> Best regards,
> >>>
> >>> Usually I pick up the power-domain related changes for the DT bindings
> >>> and host them via an immutable branch called "dt". If needed, SOC
> >>> maintainers can pull it to apply/test the corresponding DTS changes.
> >>>
> >>> That said, I am open to whatever you think is best here. Perhaps it's
> >>> easier if you can drop the DT patches and provide your acks instead or
> >>> if you can share them via an immutable branch for me to pull?
> >>
> >>
> >> I did not pick up any pmdomain binding patches. I picked up only soc and
> >> according to cover letter there are no dependencies between anything here.
> >
> > As I understand it, they are all related and some even depend on each
>
> I raised exactly that questions but no answers.
>
> > other. I think keeping all four DT patches together makes sense.
>
> Why? What is the dependency?
I defer to André to clarify this for us.
>
> >
> > Although, as I said, if you think it's best to funnel them through
> > your tree, please do and then share them via an immutable branch, so I
> > can apply the pmdomain driver changes.
>
> soc must go via my tree, but there is no reason to take the pmdomain
> binding patch. So I did not take.
Yes, they belong to soc/platform, which is common for most
power-domain providers.
To allow us to merge/maintain power-domain provider *driver* changes
separately, we needed a way to manage the corresponding DT bindings.
That's why I am hosting the immutable "dt" branch for these, which
soc/platform maintainers can pull-in when they need it.
Of course, doing it the other way around is also possible. Just let me
know what you prefer.
>
> But anyway, I just noticed that I dropped everything: this introduces
> new warnings which were nowhere addressed or explained. So regardless
> how this should go, please do not apply anything - it's broken and
> author is silent.
Right, I will await your confirmation!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: Krzysztof Kozlowski @ 2026-03-30 11:03 UTC (permalink / raw)
To: André Draszik
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <abeff7983dc08c3aeee8b504f34b71b1a2fcdb78.camel@linaro.org>
On 30/03/2026 12:59, André Draszik wrote:
> On Mon, 2026-03-30 at 12:55 +0200, Krzysztof Kozlowski wrote:
>> On 30/03/2026 12:52, André Draszik wrote:
>>>> Your patchset is organized in odd way - first patch for me, then not for
>>>> me, then again two patches for me. Please keep it consistent. Or better,
>>>> decouple since there are no dependencies according to cover letter.
>>>
>>> I'll update the cover letter to describe the dependencies. 4 depends on 2,
>>
>>
>> How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency?
>
> 4 updates the soc-level pmu binding of gs101 to have gs101-power-domain
> child-nodes, which are introduced in 2
>
You described what the patch is doing, but that was not my question.
What is the dependency exactly.
This is ping pong, so I finish discussions here, but to be clear -
entire patchset cannot be merged.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: gemini: Rename power controller node to poweroff
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260330110135.10316-1-khushalchitturi@gmail.com>
Update the node name for the Cortina Gemini power controller from
power-controller to poweroff since node "power controller" is
reserved for power domain controller.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v2 -> v3:
- Used generic node name "poweroff" instead of "gemini-poweroff".
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini/gemini.dtsi b/arch/arm/boot/dts/gemini/gemini.dtsi
index befe322bd7de..910faabf76ef 100644
--- a/arch/arm/boot/dts/gemini/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini/gemini.dtsi
@@ -228,7 +228,7 @@ intcon: interrupt-controller@48000000 {
#interrupt-cells = <2>;
};
- power-controller@4b000000 {
+ poweroff@4b000000 {
compatible = "cortina,gemini-power-controller";
reg = <0x4b000000 0x100>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260330110135.10316-1-khushalchitturi@gmail.com>
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v2 -> v3:
- Used generic node name "poweroff" instead of "gemini-poweroff".
v1 -> v2:
- Renamed the node from "power-controller" to "gemini-poweroff" to resolve dtschema warnings.
Note:
* This patch series 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
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..ef5e04f86be1
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ poweroff@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
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