* [PATCH v4 1/2] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Rakesh Kota @ 2026-03-23 10:45 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Bjorn Andersson, Konrad Dybcio
Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, Rakesh Kota,
Dmitry Baryshkov
In-Reply-To: <20260323-b4-add_pwrkey_and_resin-v4-0-abef4e4dcc3d@oss.qualcomm.com>
PMM8654AU is a different PMIC from PMM8650AU, even though both share
the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
variant.
The PMM8654AU PON block is compatible with the PMK8350 PON
implementation, but PMM8654AU also implements additional PON registers
beyond the baseline. Use the PMM8654AU naming to match the compatible
string already present in the upstream pinctrl-spmi-gpio driver, keeping
device tree and kernel driver naming consistent.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Changes in v4:
- Remove the contain for PMK8350 and new if:then for PMM8654AU as
suggested by Krzysztof Kozlowski
Changes in v3:
- Update the commit message.
Changes in v2:
- Introduces PMM8654AU compatible strings as suggested by Konrad Dybcio.
---
.../devicetree/bindings/power/reset/qcom,pon.yaml | 32 +++++++++++++++++-----
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
index 979a377cb4ffd577bfa51b9a3cd089acc202de0c..2a5d9182b8d5c1a286716ab175c7bb5e39b334e0 100644
--- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
+++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
@@ -17,12 +17,16 @@ description: |
properties:
compatible:
- enum:
- - qcom,pm8916-pon
- - qcom,pm8941-pon
- - qcom,pms405-pon
- - qcom,pm8998-pon
- - qcom,pmk8350-pon
+ oneOf:
+ - enum:
+ - qcom,pm8916-pon
+ - qcom,pm8941-pon
+ - qcom,pms405-pon
+ - qcom,pm8998-pon
+ - qcom,pmk8350-pon
+ - items:
+ - const: qcom,pmm8654au-pon
+ - const: qcom,pmk8350-pon
reg:
description: |
@@ -100,7 +104,6 @@ allOf:
- if:
properties:
compatible:
- contains:
const: qcom,pmk8350-pon
then:
properties:
@@ -113,6 +116,21 @@ allOf:
- const: hlos
- const: pbs
+ - if:
+ properties:
+ compatible:
+ const: qcom,pmm8654au-pon
+ then:
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 2
+ reg-names:
+ minItems: 1
+ items:
+ - const: hlos
+ - const: pbs
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/2] arm64: dts: qcom: monaco-pmics: Add PON power key and reset inputs
From: Rakesh Kota @ 2026-03-23 10:45 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Bjorn Andersson, Konrad Dybcio
Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, Rakesh Kota,
Konrad Dybcio
In-Reply-To: <20260323-b4-add_pwrkey_and_resin-v4-0-abef4e4dcc3d@oss.qualcomm.com>
Add the Power On (PON) peripheral with power key and reset input
support for the PMM8654AU PMIC on Monaco platforms.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Changes in v3:
- Disable the resin as suggested by the Konrad.
Changes in v2:
- Add new PMM8654AU compatible strings as suggested by the Konrad.
---
arch/arm64/boot/dts/qcom/monaco-pmics.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
index e990d7367719beaa9e0cea87d9c183ae18c3ebc8..af4c38309efae89479f9a11fcb970a4c18f03a91 100644
--- a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
@@ -13,6 +13,26 @@ pmm8620au_0: pmic@0 {
#address-cells = <1>;
#size-cells = <0>;
+ pmm8654au_0_pon: pon@1200 {
+ compatible = "qcom,pmm8654au-pon", "qcom,pmk8350-pon";
+ reg = <0x1200>, <0x800>;
+ reg-names = "hlos", "pbs";
+
+ pmm8654au_0_pon_pwrkey: pwrkey {
+ compatible = "qcom,pmm8654au-pwrkey", "qcom,pmk8350-pwrkey";
+ interrupts-extended = <&spmi_bus 0x0 0x12 0x7 IRQ_TYPE_EDGE_BOTH>;
+ linux,code = <KEY_POWER>;
+ debounce = <15625>;
+ };
+
+ pmm8654au_0_pon_resin: resin {
+ compatible = "qcom,pmm8654au-resin", "qcom,pmk8350-resin";
+ interrupts-extended = <&spmi_bus 0x0 0x12 0x6 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ status = "disabled";
+ };
+ };
+
pmm8620au_0_rtc: rtc@6100 {
compatible = "qcom,pmk8350-rtc";
reg = <0x6100>, <0x6200>;
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH 1/2] thermal/cpufreq_cooling: remove unused cpu_idx in get_load()
From: Lukasz Luba @ 2026-03-23 10:52 UTC (permalink / raw)
To: Viresh Kumar
Cc: Xuewen Yan, rui.zhang, rafael, linux-pm, amit.kachhap,
daniel.lezcano, linux-kernel, ke.wang, di.shen, jeson.gao,
xuewen.yan94
In-Reply-To: <sbtbzkzrtgrmqhxnwcqrvxprgzytkzwcsanooyukhphymgt4t6@telvhz3yolx3>
On 3/23/26 10:41, Viresh Kumar wrote:
> On 23-03-26, 09:20, Lukasz Luba wrote:
>> Thanks for monitoring the development (it's always good
>> to have extra engineer opinion)!
>>
>> I've checked the commit that you referred to and the 'i++' there.
>> It's safe. That commit removed the heavy operation for only
>> tracing purpose, namely:
>> - allocate buffer for N CPUs for 'load_cpu' pointer
>> - populate CPUs' load from the idle fwk
>> - put that info into the trace
>> - free the 'load_cpu' buffer
>>
>> That has been redesigned since it was just for tracing
>> and introducing extra time spent for code run in the
>> throttling phase.
>>
>> The code in get_load() is OK with the commit that you
>> mentioned.
>
> The code
>
> load = get_load(cpufreq_cdev, cpu, i);
>
> depends on `i` being incremented in the loop to get the correct
> `cpu_idx`. But the said commit removed it and left `i` to be set to 0
> for ever.
>
> How is that okay ? What am I missing ?
>
Right, there is a mix of two things.
The 'i' left but should be removed as well, since
this is !SMP code with only 1 cpu and i=0.
The whole split which has been made for getting
the load or utilization from CPU(s) needs to be
cleaned. The compiled code looks different since
it knows there is non-SMP config used.
Do you want to clean that or I should do this?
^ permalink raw reply
* Re: [PATCH 5/9] interconnect: qcom: define OCMEM bus resource
From: Brian Masney @ 2026-03-23 10:53 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Georgi Djakov, Konrad Dybcio, Bjorn Andersson, Luca Weiss,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260323-msm8974-icc-v1-5-7892b8d5f2ea@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 03:17:21AM +0200, Dmitry Baryshkov wrote:
> Some of the platforms (MSM8974, MSM8x26) require voting on the OCMEM
> clock. Add new resource for that clock.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH 6/9] interconnect: qcom: let platforms declare their bugginess
From: Brian Masney @ 2026-03-23 10:56 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Georgi Djakov, Konrad Dybcio, Bjorn Andersson, Luca Weiss,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260323-msm8974-icc-v1-6-7892b8d5f2ea@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 03:17:22AM +0200, Dmitry Baryshkov wrote:
> On MSM8974 programming some of the RPM resources results in the
> "resource does not exist" messages from the firmware. This occurs even
> with the downstream bus driver, which happily ignores the errors. My
> assumption is that these resources existed in the earlier firmware
> revisions but were later switched to be programmed differently (for the
> later platforms corresponding nodes use qos.ap_owned, which prevents
> those resources from being programmed.
>
> In preparation for conversion of the MSM8974 driver (which doesn't have
> QoS code yet) to the main icc-rpm set of helpers, let the driver declare
> that those -ENXIO errors must be ignored (for now). Later, when the QoS
> programming is sorted out (and more interconnects are added to the DT),
> this quirk might be removed.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
When I wrote the msm8974 icc driver, I spent a fair bit of time trying
to make it so that we didn't have to ignore those errors. As you
mentioned, the downstream msm bus code gives the same errors. That
downstream code was the only reference material that I had access to
when I wrote this driver.
^ permalink raw reply
* Re: [RFC PATCH 1/2] thermal/cpufreq_cooling: remove unused cpu_idx in get_load()
From: Viresh Kumar @ 2026-03-23 11:06 UTC (permalink / raw)
To: Lukasz Luba
Cc: Xuewen Yan, rui.zhang, rafael, linux-pm, amit.kachhap,
daniel.lezcano, linux-kernel, ke.wang, di.shen, jeson.gao,
xuewen.yan94
In-Reply-To: <c19fc390-ca3e-4ad9-92e8-e30dfd6fc95b@arm.com>
On 23-03-26, 10:52, Lukasz Luba wrote:
> > How is that okay ? What am I missing ?
I was missing !SMP :)
> Right, there is a mix of two things.
> The 'i' left but should be removed as well, since
> this is !SMP code with only 1 cpu and i=0.
>
> The whole split which has been made for getting
> the load or utilization from CPU(s) needs to be
> cleaned. The compiled code looks different since
> it knows there is non-SMP config used.
Right, we are allocating that for num_cpus (which should be 1 CPU
anyway). The entire thing must be cleaned.
> Do you want to clean that or I should do this?
It would be helpful if you can do it :)
--
viresh
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-23 11:13 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: <177409907930.268981.5882592990447577348.b4-ty@b4>
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?
Kind regards
Uffe
> --
> Krzysztof Kozlowski <krzk@kernel.org>
>
^ permalink raw reply
* Re: [PATCH] cpuidle: Deny idle entry when CPU already have IPI interrupt pending
From: Maulik Shah (mkshah) @ 2026-03-23 12:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Daniel Lezcano, Christian Loehle, Ulf Hansson, linux-pm,
linux-kernel, linux-arm-msm
In-Reply-To: <CAJZ5v0hv+t8=mT39-xOkGUS5i6vckJxwfQfqGZ4foxK2rFn8gw@mail.gmail.com>
On 3/20/2026 11:59 PM, Rafael J. Wysocki wrote:
> On Mon, Mar 16, 2026 at 8:38 AM Maulik Shah
> <maulik.shah@oss.qualcomm.com> wrote:
>>
>> CPU can get IPI interrupt from another CPU while it is executing
>> cpuidle_select() or about to execute same. The selection do not account
>> for pending interrupts and may continue to enter selected idle state only
>> to exit immediately.
>>
>> Example trace collected when there is cross CPU IPI.
>>
>> [000] 154.892148: sched_waking: comm=sugov:4 pid=491 prio=-1 target_cpu=007
>> [000] 154.892148: ipi_raise: target_mask=00000000,00000080 (Function call interrupts)
>> [007] 154.892162: cpu_idle: state=2 cpu_id=7
>> [007] 154.892208: cpu_idle: state=4294967295 cpu_id=7
>> [007] 154.892211: irq_handler_entry: irq=2 name=IPI
>> [007] 154.892211: ipi_entry: (Function call interrupts)
>> [007] 154.892213: sched_wakeup: comm=sugov:4 pid=491 prio=-1 target_cpu=007
>> [007] 154.892214: ipi_exit: (Function call interrupts)
>>
>> This impacts performance and the above count increments.
>>
>> commit ccde6525183c ("smp: Introduce a helper function to check for pending
>> IPIs") already introduced a helper function to check the pending IPIs and
>> it is used in pmdomain governor to deny the cluster level idle state when
>> there is a pending IPI on any of cluster CPUs.
>
> You seem to be overlooking the fact that resched wakeups need not be
> signaled via IPIs, but they may be updates of a monitored cache line.
>
>> This however does not stop CPU to enter CPU level idle state. Make use of
>> same at CPUidle to deny the idle entry when there is already IPI pending.
>>
>> With change observing glmark2 [1] off screen scores improving in the range
>> of 25% to 30% on Qualcomm lemans-evk board which is arm64 based having two
>> clusters each with 4 CPUs.
>>
>> [1] https://github.com/glmark2/glmark2
>>
>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>> ---
>> drivers/cpuidle/cpuidle.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> index c7876e9e024f9076663063ad21cfc69343fdbbe7..c88c0cbf910d6c2c09697e6a3ac78c081868c2ad 100644
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@ -224,6 +224,9 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev,
>> bool broadcast = !!(target_state->flags & CPUIDLE_FLAG_TIMER_STOP);
>> ktime_t time_start, time_end;
>>
>> + if (cpus_peek_for_pending_ipi(drv->cpumask))
>> + return -EBUSY;
>> +
>
> So what if the driver handles all CPUs in the system and there are
> many of them (say ~500) and if IPIs occur rarely (because resched
> events are not IPIs)?
Missed the case of driver handling multiple CPUs,
In v2 would fix this as below, which checks pending IPI on single
CPU trying to enter idle.
if (cpus_peek_for_pending_ipi(cpumask_of(dev->cpu)))
I see IPIs do occur often, in the glmark2 offscreen case
mentioned in commit text, out of total ~12.2k IPIs across all 8 CPUs,
~9.6k are function call IPIs, ~2k are IRQ work IPIs, ~560 Timer broadcast
IPIs while rescheduling IPIs are only 82.
Thanks,
Maulik
>
>> instrumentation_begin();
>>
>> /*
>>
>> ---
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-03-23 12:16 UTC (permalink / raw)
To: Rob Herring
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <20260322233713.GA98177-robh@kernel.org>
On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > spec, it looks very similar to the M.2 Key E connector. So add the
> > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > to reuse the Key E binding.
>
> What is LGA?
>
Land Grid Array
> If not in the spec, is it really something generic?
>
Good question. Yes and No! LGA is not something that Lenovo only uses. Other
vendors may also use this form factor. PCIe connectors are full of innovation as
the spec gives room for hardware designers to be as innovative as possible to
save the BOM cost.
This is why I do not want to make it Lenovo specific. But if you prefer that, I
can name it as "lenovo,pcie-m2-1620-lga-connector".
- Mani
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > .../devicetree/bindings/connector/pcie-m2-e-connector.yaml | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > index f7859aa9b634..d8cf9a9ec7d0 100644
> > --- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > @@ -17,7 +17,14 @@ description:
> >
> > properties:
> > compatible:
> > - const: pcie-m2-e-connector
> > + oneOf:
> > + - items:
> > + - enum:
> > + - pcie-m2-1620-lga-connector
> > + - const: pcie-m2-e-connector
> > + - items:
> > + - enum:
> > + - pcie-m2-e-connector
> >
> > vpcie3v3-supply:
> > description: A phandle to the regulator for 3.3v supply.
> >
> > --
> > 2.51.0
> >
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
From: Konrad Dybcio @ 2026-03-23 12:29 UTC (permalink / raw)
To: Daniel Lezcano, Gaurav Kohli, Krzysztof Kozlowski
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, rui.zhang,
lukasz.luba, konradybcio, mani, casey.connolly, amit.kucheria,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
manaf.pallikunhi
In-Reply-To: <909009ab-53fe-4b20-ad2c-bc8eac9e8bc1@oss.qualcomm.com>
On 3/21/26 10:00 AM, Daniel Lezcano wrote:
>
> Hi Konrad,
>
> On 3/19/26 10:51, Konrad Dybcio wrote:
>> On 3/18/26 11:17 AM, Gaurav Kohli wrote:
>>>
>>>
>>> On 3/17/2026 1:27 AM, Daniel Lezcano wrote:
>>>> On Tue, Feb 24, 2026 at 01:17:22PM +0100, Krzysztof Kozlowski wrote:
>>>>> On 24/02/2026 13:09, Gaurav Kohli wrote:
>>>>
>>>> [ ... ]
>>>>
>>>>>>>> As a result, each core requires its own cooling device, which must be
>>>>>>>> linked to its TSENS thermal zone. Because of this, we introduced
>>>>>>>> multiple child nodes—one for each cooling device.
>>>>>>>
>>>>>>> So you have one device with cooling cells=1+2, no?
>>>>>>>
>>>>>>
>>>>>> This will be a bigger framework change which is not supported, i can see
>>>>>
>>>>> I don't think that changing open source frameworks is "not supported". I
>>>>> am pretty sure that changing is not only supported, but actually desired.
>>>>
>>>> Yes, IMO it could make sense. There are the thermal zones with phandle
>>>> to a sensor and a sensor id. We can have the same with a phandle to a
>>>> cooling device and a cooling device id.
>>>>
>>>> (... or several ids because the thermal sensor can also have multiple
>>>> ids ?)
>>>>
>>>> May be an array of names corresponding to the TMD names at the 'id'
>>>> position ?
>>>>
>>>
>>> I am using dt node like below to use with cooling-cells = <3> approach, will post new patches with that.
>>>
>>> cdsp_tmd: cdsp-tmd {
>>> compatible = "qcom,qmi-cooling-cdsp";
>>> tmd-names = "cdsp_sw", "cdsp_hw";
>>> #cooling-cells = <3>;
>>> };
>>>
>>> please let me know, if you are expecting something like this only.
>>
>> My question about the need of a separate node still remains, i.e.
>> why can't this be:
>>
>> remoteproc_cdsp: remoteproc@cafebabe {
>> compatible = "qcom,foo-cdsp"
>>
>> ...
>>
>> tmd-names = "abc", "xyz";
>> #cooling-cells = <3>;
>> };
>>
>>
>>
>> foo-thermal {
>> cooling-maps {
>> map0 {
>> cooling-device = <&remoteproc_cdsp CDSP_COOLING_XYZ
>> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>> };
>> };
>> };
>>
>> where you'd presumably call something like qmi_cooling_register(...) from
>> the remoteproc driver, making your added code essentially a library, not a
>> separate platform device
>
> I'm not sure to get your question. My understanding of the 3 cooling-cells is exactly what you described. The second argument of the cooling-device map is an index corresponding to the id of the TMD. BTW I prefer also the compatible name like 'qcom,foo-cdsp'
My specific suggestion is to _not_ spawn an additional node, since all
of this logic relates to the behavior of the (e.g.) CDSP, which already
has its own node
Konrad
^ permalink raw reply
* Re: [PATCH v1 1/2] PM: wakeup: Add kfuncs to lock/unlock wakeup_sources
From: kernel test robot @ 2026-03-23 12:33 UTC (permalink / raw)
To: Samuel Wu, Rafael J. Wysocki, Len Brown, Pavel Machek,
Greg Kroah-Hartman, Danilo Krummrich
Cc: oe-kbuild-all, andrii, memxor, bpf, Samuel Wu, kernel-team,
linux-pm, driver-core, linux-kernel
In-Reply-To: <20260320160055.4114055-2-wusamuel@google.com>
Hi Samuel,
kernel test robot noticed the following build warnings:
[auto build test WARNING on rafael-pm/linux-next]
[also build test WARNING on rafael-pm/bleeding-edge linus/master v7.0-rc5 next-20260320]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Samuel-Wu/PM-wakeup-Add-kfuncs-to-lock-unlock-wakeup_sources/20260323-064540
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link: https://lore.kernel.org/r/20260320160055.4114055-2-wusamuel%40google.com
patch subject: [PATCH v1 1/2] PM: wakeup: Add kfuncs to lock/unlock wakeup_sources
config: x86_64-randconfig-121-20260323 (https://download.01.org/0day-ci/archive/20260323/202603232018.pdjbZ3eL-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.4.0-5) 12.4.0
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603232018.pdjbZ3eL-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/202603232018.pdjbZ3eL-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/base/power/wakeup.c:1189:32: sparse: sparse: symbol 'bpf_wakeup_sources_read_lock' was not declared. Should it be static?
>> drivers/base/power/wakeup.c:1202:18: sparse: sparse: symbol 'bpf_wakeup_sources_read_unlock' was not declared. Should it be static?
vim +/bpf_wakeup_sources_read_lock +1189 drivers/base/power/wakeup.c
1177
1178 /**
1179 * bpf_wakeup_sources_read_lock - Acquire the SRCU lock for wakeup sources
1180 *
1181 * The underlying SRCU lock returns an integer index. However, the BPF verifier
1182 * requires a pointer (PTR_TO_BTF_ID) to strictly track the state of acquired
1183 * resources using KF_ACQUIRE and KF_RELEASE semantics. We use an opaque
1184 * structure pointer (struct bpf_ws_lock *) to satisfy the verifier while
1185 * safely encoding the integer index within the pointer address itself.
1186 *
1187 * Return: An opaque pointer encoding the SRCU lock index + 1 (to avoid NULL).
1188 */
> 1189 __bpf_kfunc struct bpf_ws_lock *bpf_wakeup_sources_read_lock(void)
1190 {
1191 return (struct bpf_ws_lock *)(long)(wakeup_sources_read_lock() + 1);
1192 }
1193
1194 /**
1195 * bpf_wakeup_sources_read_unlock - Release the SRCU lock for wakeup sources
1196 * @lock: The opaque pointer returned by bpf_wakeup_sources_read_lock()
1197 *
1198 * The BPF verifier guarantees that @lock is a valid, unreleased pointer from
1199 * the acquire function. We decode the pointer back into the integer SRCU index
1200 * by subtracting 1 and release the lock.
1201 */
> 1202 __bpf_kfunc void bpf_wakeup_sources_read_unlock(struct bpf_ws_lock *lock)
1203 {
1204 wakeup_sources_read_unlock((int)(long)lock - 1);
1205 }
1206
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 0/5] Support enabling interconnect path for GDSC for fixing Milos camcc
From: Konrad Dybcio @ 2026-03-23 12:46 UTC (permalink / raw)
To: Luca Weiss, Georgi Djakov, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Mike Tipton
Cc: ~postmarketos/upstreaming, phone-devel, linux-pm, linux-kernel,
linux-arm-msm, linux-clk, devicetree
In-Reply-To: <20260116-milos-camcc-icc-v1-0-400b7fcd156a@fairphone.com>
On 1/16/26 2:17 PM, Luca Weiss wrote:
> Some power domains like CAMSS_TOP_GDSC requires the enablement of the
> multimedia NoC on newer SoCs like Milos.
>
> Add support for getting an interconnect path as specified in the SoC
> clock driver, and enabling/disabling that interconnect path when the
> GDSC is being enabled/disabled.
>
> Then specify that dependency in the camcc-milos driver and add it to the
> dt-bindings and milos.dtsi.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
+Mike could you please take a look?
Konrad
^ permalink raw reply
* Re: [PATCH] PM: sleep: Drop spurious WARN_ON from pm_restore_gfp_mask()
From: Rafael J. Wysocki @ 2026-03-23 13:06 UTC (permalink / raw)
To: Youngjun Park
Cc: Rafael J . Wysocki, Len Brown, Pavel Machek, linux-pm,
Andrew Morton, Chris Li, Kairui Song
In-Reply-To: <20260322120528.750178-1-youngjun.park@lge.com>
On Sun, Mar 22, 2026 at 1:05 PM Youngjun Park <youngjun.park@lge.com> wrote:
>
> Commit 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask()
> stacking") introduced refcount-based GFP mask management that warns
> when pm_restore_gfp_mask() is called with saved_gfp_count == 0.
>
> Some hibernation paths call pm_restore_gfp_mask() defensively where
> the GFP mask may or may not be restricted depending on the execution
> path. For example, the uswsusp interface invokes it in
> SNAPSHOT_CREATE_IMAGE, SNAPSHOT_UNFREEZE, and snapshot_release().
> Before the stacking change this was a silent no-op; it now triggers
> a spurious WARNING.
>
> Remove the WARN_ON() wrapper from the !saved_gfp_count check while
> retaining the check itself, so that defensive calls remain harmless
> without producing false warnings.
>
> Fixes: 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask() stacking")
> Signed-off-by: Youngjun Park <youngjun.park@lge.com>
> ---
> ---
> Split from the earlier pm_restore_gfp_mask_nowarn() series and
> agreed upon with Rafael to take this simpler approach instead:
> https://lore.kernel.org/linux-mm/CAJZ5v0gBHLz7T2qRJRjBfOWY6UXM6L6+Kw8UcsY4+OaB7+qQcg@mail.gmail.com/T/#m10ee3346cd8dcd052749105d9a8e2052dbf3bc80
>
> kernel/power/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index 5f8c9e12eaec..5429e9f19b65 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -40,7 +40,7 @@ void pm_restore_gfp_mask(void)
> {
> WARN_ON(!mutex_is_locked(&system_transition_mutex));
>
> - if (WARN_ON(!saved_gfp_count) || --saved_gfp_count)
> + if (!saved_gfp_count || --saved_gfp_count)
> return;
>
> gfp_allowed_mask = saved_gfp_mask;
>
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> --
Applied as 7.0-rc material, thanks!
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sm8750: Enable TSENS and thermal zones
From: Konrad Dybcio @ 2026-03-23 13:12 UTC (permalink / raw)
To: Gaurav Kohli, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-pm, linux-arm-msm, devicetree, linux-kernel, aastha.pandey,
dipa.mantre, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <b7b19386-510e-4892-84db-09a20bca635f@oss.qualcomm.com>
On 3/23/26 10:02 AM, Gaurav Kohli wrote:
>
>
> On 3/18/2026 3:14 PM, Konrad Dybcio wrote:
>> On 3/13/26 11:34 AM, Gaurav Kohli wrote:
>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>
>>> The sm8750 includes four TSENS instances, with a total of 47 thermal
>>> sensors distributed across various locations on the SoC.
>>>
>>> The TSENS max/reset threshold is configured to 130°C in the hardware.
>>> Enable all TSENS instances, and define the thermal zones with a hot trip
>>> at 120°C and critical trip at 125°C.
>>>
>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> + cpu-0-0-0-thermal {
>>> + thermal-sensors = <&tsens0 1>;
>>> +
>>> + trips {
>>> + trip-point0 {
>>> + temperature = <120000>;
>>> + hysteresis = <5000>;
>>> + type = "hot";
>>> + };
>>
>> Are we going to use these trip points for the CPUs? If not, let's only
>> keep the critical ones (again, for CPUs specifically since they get
>> externally throttled)
>
> thanks Konrad, for review.
> We are not using this trip points for CPUs, For Kaanapali, Dmitry suggested to add more warning for CPUs also, if in case some user want to use it. So we have added for this soc also.
Alright, please resubmit with Krzysztof's comments addressed and retain
my r-b then
Konrad
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Rob Herring (Arm) @ 2026-03-23 13:24 UTC (permalink / raw)
To: Rakesh Kota
Cc: Krzysztof Kozlowski, linux-pm, linux-kernel, Bjorn Andersson,
devicetree, Conor Dooley, Konrad Dybcio, Vinod Koul,
Dmitry Baryshkov, Sebastian Reichel, linux-arm-msm
In-Reply-To: <20260323-b4-add_pwrkey_and_resin-v4-1-abef4e4dcc3d@oss.qualcomm.com>
On Mon, 23 Mar 2026 16:15:15 +0530, Rakesh Kota wrote:
> PMM8654AU is a different PMIC from PMM8650AU, even though both share
> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
> variant.
>
> The PMM8654AU PON block is compatible with the PMK8350 PON
> implementation, but PMM8654AU also implements additional PON registers
> beyond the baseline. Use the PMM8654AU naming to match the compatible
> string already present in the upstream pinctrl-spmi-gpio driver, keeping
> device tree and kernel driver naming consistent.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> ---
> Changes in v4:
> - Remove the contain for PMK8350 and new if:then for PMM8654AU as
> suggested by Krzysztof Kozlowski
>
> Changes in v3:
> - Update the commit message.
>
> Changes in v2:
> - Introduces PMM8654AU compatible strings as suggested by Konrad Dybcio.
> ---
> .../devicetree/bindings/power/reset/qcom,pon.yaml | 32 +++++++++++++++++-----
> 1 file changed, 25 insertions(+), 7 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/power/reset/qcom,pon.yaml:107:13: [warning] wrong indentation: expected 10 but found 12 (indentation)
./Documentation/devicetree/bindings/power/reset/qcom,pon.yaml:122:13: [warning] wrong indentation: expected 10 but found 12 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260323-b4-add_pwrkey_and_resin-v4-1-abef4e4dcc3d@oss.qualcomm.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
* Re: [RFC PATCH 1/2] thermal/cpufreq_cooling: remove unused cpu_idx in get_load()
From: Lukasz Luba @ 2026-03-23 13:25 UTC (permalink / raw)
To: Viresh Kumar, Xuewen Yan
Cc: rui.zhang, rafael, linux-pm, amit.kachhap, daniel.lezcano,
linux-kernel, ke.wang, di.shen, jeson.gao, xuewen.yan94
In-Reply-To: <psrlnsgdg4afrbk7u3vq35bsqc5msncrfifrl6ee45usn27r7y@fwjklu6mcutw>
On 3/23/26 11:06, Viresh Kumar wrote:
> On 23-03-26, 10:52, Lukasz Luba wrote:
>>> How is that okay ? What am I missing ?
>
> I was missing !SMP :)
>
>> Right, there is a mix of two things.
>> The 'i' left but should be removed as well, since
>> this is !SMP code with only 1 cpu and i=0.
>>
>> The whole split which has been made for getting
>> the load or utilization from CPU(s) needs to be
>> cleaned. The compiled code looks different since
>> it knows there is non-SMP config used.
>
> Right, we are allocating that for num_cpus (which should be 1 CPU
> anyway). The entire thing must be cleaned.
>
>> Do you want to clean that or I should do this?
>
> It would be helpful if you can do it :)
>
OK, I will. Thanks for your involvement Viresh!
Xuewen please wait with your v2, I will send
a redesign of this left code today.
^ permalink raw reply
* [PATCH 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-23 13:38 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 renames thermal_flags property in spear13xx.dtsi to
st,thermal-flags to fix the unevaluated property warning in
st/spear1340-evb.dts.
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: fix dtbs warning on spear thermal sensor
.../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
* [PATCH 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-23 13:38 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: <20260323133814.14152-1-krishnagopi487@gmail.com>
Convert the SPEAr Thermal Sensor bindings to DT schema.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@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
.../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..125632163911
--- /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
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ thermal@fc000000 {
+ compatible = "st,thermal-spear1340";
+ reg = <0xfc000000 0x1000>;
+ st,thermal-flags = <0x7000>;
+ };
--
2.52.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Gopi Krishna Menon @ 2026-03-23 13:38 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: <20260323133814.14152-1-krishnagopi487@gmail.com>
Running DTBS checks on st/spear1340-evb.dtb results in the following
warning:
thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
Rename thermal_flags to st,thermal-flags to fix the warning.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@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
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
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Rob Herring @ 2026-03-23 13:39 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <to2mrizprc3hjufqbiplpqyek7f4uutqtn4hx4gkmdgv2rykbc@ybwwjhdec4nm>
On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > to reuse the Key E binding.
> >
> > What is LGA?
> >
>
> Land Grid Array
>
> > If not in the spec, is it really something generic?
> >
>
> Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> vendors may also use this form factor. PCIe connectors are full of innovation as
> the spec gives room for hardware designers to be as innovative as possible to
> save the BOM cost.
innovation == incompatible changes
> This is why I do not want to make it Lenovo specific. But if you prefer that, I
> can name it as "lenovo,pcie-m2-1620-lga-connector".
Depends if you think that s/w needs to know the differences. Hard to
say with a sample size of 1.
Rob
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-03-23 13:44 UTC (permalink / raw)
To: Rob Herring
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <CAL_JsqJXrHCJt770bJkMmAUhirSF3kHjYwSzkG7cXp7-eys8Rg@mail.gmail.com>
On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > to reuse the Key E binding.
> > >
> > > What is LGA?
> > >
> >
> > Land Grid Array
> >
> > > If not in the spec, is it really something generic?
> > >
> >
> > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > vendors may also use this form factor. PCIe connectors are full of innovation as
> > the spec gives room for hardware designers to be as innovative as possible to
> > save the BOM cost.
>
> innovation == incompatible changes
>
Yes, I was trying to sound nice :)
> > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > can name it as "lenovo,pcie-m2-1620-lga-connector".
>
> Depends if you think that s/w needs to know the differences. Hard to
> say with a sample size of 1.
>
Sure. Will add the 'lenovo' prefix then.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] thermal: devfreq_cooling: avoid unnecessary kfree of freq_table
From: Rafael J. Wysocki @ 2026-03-23 13:52 UTC (permalink / raw)
To: Lukasz Luba, Anas Iqbal
Cc: rui.zhang, daniel.lezcano, linux-pm, rafael, linux-kernel
In-Reply-To: <d46ef894-ff62-4493-bd17-660004640eca@arm.com>
On Mon, Mar 23, 2026 at 11:44 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
>
>
> On 3/23/26 09:40, Anas Iqbal wrote:
> > dfc->freq_table is only allocated in the non-EM path via
> > devfreq_cooling_gen_tables(). In the EM path, it remains NULL.
> >
> > Avoid calling kfree() unnecessarily when freq_table was never allocated.
> >
> > This resolves a Smatch warning:
> > calling kfree() when 'dfc->freq_table' is always NULL.
> >
> > Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
> > ---
> > drivers/thermal/devfreq_cooling.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/devfreq_cooling.c b/drivers/thermal/devfreq_cooling.c
> > index 597e86d16a4e..1c7dffc8d45f 100644
> > --- a/drivers/thermal/devfreq_cooling.c
> > +++ b/drivers/thermal/devfreq_cooling.c
> > @@ -472,7 +472,8 @@ of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df,
> > remove_qos_req:
> > dev_pm_qos_remove_request(&dfc->req_max_freq);
> > free_table:
> > - kfree(dfc->freq_table);
> > + if (!dfc->em_pd)
> > + kfree(dfc->freq_table);
> > free_dfc:
> > kfree(dfc);
> >
>
> LGTM, let's calm down that warning.
>
> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Applied as 7.1 material, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
From: Daniel Lezcano @ 2026-03-23 14:19 UTC (permalink / raw)
To: Konrad Dybcio, Gaurav Kohli, Krzysztof Kozlowski
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, rui.zhang,
lukasz.luba, konradybcio, mani, casey.connolly, amit.kucheria,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
manaf.pallikunhi
In-Reply-To: <7e50100a-514f-4f73-a976-9858ce5cc0e1@oss.qualcomm.com>
On 3/23/26 13:29, Konrad Dybcio wrote:
> On 3/21/26 10:00 AM, Daniel Lezcano wrote:
>>
>> Hi Konrad,
[ ... ]
> My specific suggestion is to _not_ spawn an additional node, since
> all of this logic relates to the behavior of the (e.g.) CDSP, which
> already has its own node
Got it thanks !
+1
^ permalink raw reply
* Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
From: Gaurav Kohli @ 2026-03-23 14:25 UTC (permalink / raw)
To: Daniel Lezcano, Konrad Dybcio, Krzysztof Kozlowski
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, rui.zhang,
lukasz.luba, konradybcio, mani, casey.connolly, amit.kucheria,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
manaf.pallikunhi
In-Reply-To: <2d1d6fd3-b34b-4eea-a4b7-0085a6a7342e@oss.qualcomm.com>
On 3/23/2026 7:49 PM, Daniel Lezcano wrote:
> On 3/23/26 13:29, Konrad Dybcio wrote:
>> On 3/21/26 10:00 AM, Daniel Lezcano wrote:
>>>
>>> Hi Konrad,
>
> [ ... ]
>
>> My specific suggestion is to _not_ spawn an additional node, since
>> all of this logic relates to the behavior of the (e.g.) CDSP, which
>> already has its own node
>
> Got it thanks !
>
> +1
thanks for the review & guidance for the design.
working on it, will come back with a new version.
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Dmitry Baryshkov @ 2026-03-23 15:14 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Rob Herring, Manivannan Sadhasivam, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, linux-acpi
In-Reply-To: <6aef3xxjjd4nbgrfx6jc6jt6rpqmttoui6hil5zqgdpas2j6gj@ie6j72orenou>
On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > > to reuse the Key E binding.
> > > >
> > > > What is LGA?
> > > >
> > >
> > > Land Grid Array
> > >
> > > > If not in the spec, is it really something generic?
> > > >
> > >
> > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > the spec gives room for hardware designers to be as innovative as possible to
> > > save the BOM cost.
> >
> > innovation == incompatible changes
> >
>
> Yes, I was trying to sound nice :)
>
> > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> >
> > Depends if you think that s/w needs to know the differences. Hard to
> > say with a sample size of 1.
> >
>
> Sure. Will add the 'lenovo' prefix then.
Is it really Lenovo? Or is it some other module vendor, whose LGAs are
being used by Lenovo?
I remember that DB820c also used some kind of a module for the WiFi card
(which might be M.2 compatible or might not, I can't find exact docs at
this point).
--
With best wishes
Dmitry
^ 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