* [PATCH v2 0/3] QCM2290 LMH
@ 2024-03-09 13:15 Konrad Dybcio
2024-03-09 13:15 ` [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible Konrad Dybcio
` (4 more replies)
0 siblings, 5 replies; 18+ messages in thread
From: Konrad Dybcio @ 2024-03-09 13:15 UTC (permalink / raw
To: Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, Konrad Dybcio, stable, Loic Poulain
Wire up LMH on QCM2290 and fix a bad bug while at it.
P1-2 for thermal, P3 for qcom
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Changes in v2:
- Pick up tags
- Fix a couple typos in commit messages
- Drop stray msm8998 binding addition
- Link to v1: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v1-0-50c60ffe1130@linaro.org
---
Konrad Dybcio (2):
dt-bindings: thermal: lmh: Add QCM2290 compatible
thermal: qcom: lmh: Check for SCM availability at probe
Loic Poulain (1):
arm64: dts: qcom: qcm2290: Add LMH node
Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
drivers/thermal/qcom/lmh.c | 3 +++
3 files changed, 24 insertions(+), 5 deletions(-)
---
base-commit: 8ffc8b1bbd505e27e2c8439d326b6059c906c9dd
change-id: 20240308-topic-rb1_lmh-1e0f440c392a
Best regards,
--
Konrad Dybcio <konrad.dybcio@linaro.org>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible
2024-03-09 13:15 [PATCH v2 0/3] QCM2290 LMH Konrad Dybcio
@ 2024-03-09 13:15 ` Konrad Dybcio
2024-03-10 8:49 ` Krzysztof Kozlowski
` (2 more replies)
2024-03-09 13:15 ` [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe Konrad Dybcio
` (3 subsequent siblings)
4 siblings, 3 replies; 18+ messages in thread
From: Konrad Dybcio @ 2024-03-09 13:15 UTC (permalink / raw
To: Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, Konrad Dybcio
Document the QCM2290 LMH.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
index 5ff72ce5c887..1175bb358382 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
@@ -17,10 +17,14 @@ description:
properties:
compatible:
- enum:
- - qcom,sc8180x-lmh
- - qcom,sdm845-lmh
- - qcom,sm8150-lmh
+ oneOf:
+ - enum:
+ - qcom,sc8180x-lmh
+ - qcom,sdm845-lmh
+ - qcom,sm8150-lmh
+ - items:
+ - const: qcom,qcm2290-lmh
+ - const: qcom,sm8150-lmh
reg:
items:
--
2.44.0
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe
2024-03-09 13:15 [PATCH v2 0/3] QCM2290 LMH Konrad Dybcio
2024-03-09 13:15 ` [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible Konrad Dybcio
@ 2024-03-09 13:15 ` Konrad Dybcio
2024-03-18 1:27 ` Bjorn Andersson
` (2 more replies)
2024-03-09 13:15 ` [PATCH v2 3/3] arm64: dts: qcom: qcm2290: Add LMH node Konrad Dybcio
` (2 subsequent siblings)
4 siblings, 3 replies; 18+ messages in thread
From: Konrad Dybcio @ 2024-03-09 13:15 UTC (permalink / raw
To: Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, Konrad Dybcio, stable
Up until now, the necessary scm availability check has not been
performed, leading to possible null pointer dereferences (which did
happen for me on RB1).
Fix that.
Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/thermal/qcom/lmh.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
index f6edb12ec004..5225b3621a56 100644
--- a/drivers/thermal/qcom/lmh.c
+++ b/drivers/thermal/qcom/lmh.c
@@ -95,6 +95,9 @@ static int lmh_probe(struct platform_device *pdev)
unsigned int enable_alg;
u32 node_id;
+ if (!qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
lmh_data = devm_kzalloc(dev, sizeof(*lmh_data), GFP_KERNEL);
if (!lmh_data)
return -ENOMEM;
--
2.44.0
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v2 3/3] arm64: dts: qcom: qcm2290: Add LMH node
2024-03-09 13:15 [PATCH v2 0/3] QCM2290 LMH Konrad Dybcio
2024-03-09 13:15 ` [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible Konrad Dybcio
2024-03-09 13:15 ` [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe Konrad Dybcio
@ 2024-03-09 13:15 ` Konrad Dybcio
2024-03-19 2:48 ` (subset) [PATCH v2 0/3] QCM2290 LMH Bjorn Andersson
2024-03-20 19:08 ` Nícolas F. R. A. Prado
4 siblings, 0 replies; 18+ messages in thread
From: Konrad Dybcio @ 2024-03-09 13:15 UTC (permalink / raw
To: Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, Konrad Dybcio, Loic Poulain
From: Loic Poulain <loic.poulain@linaro.org>
Add a node for the Limits Management Hardware to ensure it can be
configured by the operating system.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
[Konrad: add commit msg, rebase]
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
index 89beac833d43..1aacad50e7fc 100644
--- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
@@ -1858,7 +1858,7 @@ cpufreq_hw: cpufreq@f521000 {
compatible = "qcom,qcm2290-cpufreq-hw", "qcom,cpufreq-hw";
reg = <0x0 0x0f521000 0x0 0x1000>;
reg-names = "freq-domain0";
- interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts-extended = <&lmh_cluster 0>;
interrupt-names = "dcvsh-irq-0";
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&gcc GPLL0>;
clock-names = "xo", "alternate";
@@ -1866,6 +1866,18 @@ cpufreq_hw: cpufreq@f521000 {
#freq-domain-cells = <1>;
#clock-cells = <1>;
};
+
+ lmh_cluster: lmh@f550800 {
+ compatible = "qcom,qcm2290-lmh", "qcom,sm8150-lmh";
+ reg = <0x0 0x0f550800 0x0 0x400>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ cpus = <&CPU0>;
+ qcom,lmh-temp-arm-millicelsius = <65000>;
+ qcom,lmh-temp-low-millicelsius = <94500>;
+ qcom,lmh-temp-high-millicelsius = <95000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
thermal-zones {
--
2.44.0
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible
2024-03-09 13:15 ` [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible Konrad Dybcio
@ 2024-03-10 8:49 ` Krzysztof Kozlowski
2024-03-21 17:13 ` Daniel Lezcano
2024-05-14 10:18 ` [thermal: thermal/fixes] " thermal-bot for Konrad Dybcio
2 siblings, 0 replies; 18+ messages in thread
From: Krzysztof Kozlowski @ 2024-03-10 8:49 UTC (permalink / raw
To: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thara Gopinath, Amit Kucheria
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov
On 09/03/2024 14:15, Konrad Dybcio wrote:
> Document the QCM2290 LMH.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe
2024-03-09 13:15 ` [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe Konrad Dybcio
@ 2024-03-18 1:27 ` Bjorn Andersson
2024-03-21 17:13 ` Daniel Lezcano
2024-05-14 10:18 ` [thermal: thermal/fixes] thermal/drivers/qcom/lmh: " thermal-bot for Konrad Dybcio
2 siblings, 0 replies; 18+ messages in thread
From: Bjorn Andersson @ 2024-03-18 1:27 UTC (permalink / raw
To: Konrad Dybcio
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thara Gopinath,
Amit Kucheria, Marijn Suijten, linux-arm-msm, linux-pm,
devicetree, linux-kernel, Dmitry Baryshkov, stable
On Sat, Mar 09, 2024 at 02:15:03PM +0100, Konrad Dybcio wrote:
> Up until now, the necessary scm availability check has not been
> performed, leading to possible null pointer dereferences (which did
> happen for me on RB1).
>
> Fix that.
>
> Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
> Cc: <stable@vger.kernel.org>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Regards,
Bjorn
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: (subset) [PATCH v2 0/3] QCM2290 LMH
2024-03-09 13:15 [PATCH v2 0/3] QCM2290 LMH Konrad Dybcio
` (2 preceding siblings ...)
2024-03-09 13:15 ` [PATCH v2 3/3] arm64: dts: qcom: qcm2290: Add LMH node Konrad Dybcio
@ 2024-03-19 2:48 ` Bjorn Andersson
2024-03-20 19:08 ` Nícolas F. R. A. Prado
4 siblings, 0 replies; 18+ messages in thread
From: Bjorn Andersson @ 2024-03-19 2:48 UTC (permalink / raw
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thara Gopinath,
Amit Kucheria, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, stable, Loic Poulain
On Sat, 09 Mar 2024 14:15:01 +0100, Konrad Dybcio wrote:
> Wire up LMH on QCM2290 and fix a bad bug while at it.
>
> P1-2 for thermal, P3 for qcom
>
>
Applied, thanks!
[3/3] arm64: dts: qcom: qcm2290: Add LMH node
commit: 7d6d561fa934594faf359f6fffee0e2dd59f8110
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] QCM2290 LMH
2024-03-09 13:15 [PATCH v2 0/3] QCM2290 LMH Konrad Dybcio
` (3 preceding siblings ...)
2024-03-19 2:48 ` (subset) [PATCH v2 0/3] QCM2290 LMH Bjorn Andersson
@ 2024-03-20 19:08 ` Nícolas F. R. A. Prado
2024-03-25 19:48 ` Konrad Dybcio
2024-03-25 19:59 ` Krzysztof Kozlowski
4 siblings, 2 replies; 18+ messages in thread
From: Nícolas F. R. A. Prado @ 2024-03-20 19:08 UTC (permalink / raw
To: Konrad Dybcio
Cc: Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria, Marijn Suijten, linux-arm-msm,
linux-pm, devicetree, linux-kernel, Dmitry Baryshkov, stable,
Loic Poulain
On Sat, Mar 09, 2024 at 02:15:01PM +0100, Konrad Dybcio wrote:
> Wire up LMH on QCM2290 and fix a bad bug while at it.
>
> P1-2 for thermal, P3 for qcom
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> Changes in v2:
> - Pick up tags
> - Fix a couple typos in commit messages
> - Drop stray msm8998 binding addition
> - Link to v1: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v1-0-50c60ffe1130@linaro.org
>
> ---
> Konrad Dybcio (2):
> dt-bindings: thermal: lmh: Add QCM2290 compatible
> thermal: qcom: lmh: Check for SCM availability at probe
>
> Loic Poulain (1):
> arm64: dts: qcom: qcm2290: Add LMH node
>
> Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
> drivers/thermal/qcom/lmh.c | 3 +++
> 3 files changed, 24 insertions(+), 5 deletions(-)
Hi,
I've started tracking the results of 'make dtbs_check' on linux-next, and I've
noticed that on today's next, next-20240320, there's a new warning coming from
this. The reason is that the DT change has landed, but the binding has not,
since it goes through a separate tree. I thought the binding was supposed to
always land before the driver and DT that make use of it, but looking through
the dt-binding documentation pages I couldn't find anything confirming or
denying that.
I expect this to happen again in the future, which is why I'm reaching out to
understand better how to deal with this kind of situation.
Thanks,
Nícolas
> ---
> base-commit: 8ffc8b1bbd505e27e2c8439d326b6059c906c9dd
> change-id: 20240308-topic-rb1_lmh-1e0f440c392a
>
> Best regards,
> --
> Konrad Dybcio <konrad.dybcio@linaro.org>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible
2024-03-09 13:15 ` [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible Konrad Dybcio
2024-03-10 8:49 ` Krzysztof Kozlowski
@ 2024-03-21 17:13 ` Daniel Lezcano
2024-05-14 10:18 ` [thermal: thermal/fixes] " thermal-bot for Konrad Dybcio
2 siblings, 0 replies; 18+ messages in thread
From: Daniel Lezcano @ 2024-03-21 17:13 UTC (permalink / raw
To: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov
On 09/03/2024 14:15, Konrad Dybcio wrote:
> Document the QCM2290 LMH.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
Applied, thanks
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe
2024-03-09 13:15 ` [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe Konrad Dybcio
2024-03-18 1:27 ` Bjorn Andersson
@ 2024-03-21 17:13 ` Daniel Lezcano
2024-05-14 10:18 ` [thermal: thermal/fixes] thermal/drivers/qcom/lmh: " thermal-bot for Konrad Dybcio
2 siblings, 0 replies; 18+ messages in thread
From: Daniel Lezcano @ 2024-03-21 17:13 UTC (permalink / raw
To: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria
Cc: Marijn Suijten, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, stable
On 09/03/2024 14:15, Konrad Dybcio wrote:
> Up until now, the necessary scm availability check has not been
> performed, leading to possible null pointer dereferences (which did
> happen for me on RB1).
>
> Fix that.
>
> Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
> Cc: <stable@vger.kernel.org>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
Applied, thanks
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] QCM2290 LMH
2024-03-20 19:08 ` Nícolas F. R. A. Prado
@ 2024-03-25 19:48 ` Konrad Dybcio
2024-03-25 19:59 ` Krzysztof Kozlowski
1 sibling, 0 replies; 18+ messages in thread
From: Konrad Dybcio @ 2024-03-25 19:48 UTC (permalink / raw
To: Nícolas F. R. A. Prado
Cc: Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria, Marijn Suijten, linux-arm-msm,
linux-pm, devicetree, linux-kernel, Dmitry Baryshkov, stable,
Loic Poulain
On 20.03.2024 8:08 PM, Nícolas F. R. A. Prado wrote:
> On Sat, Mar 09, 2024 at 02:15:01PM +0100, Konrad Dybcio wrote:
>> Wire up LMH on QCM2290 and fix a bad bug while at it.
>>
>> P1-2 for thermal, P3 for qcom
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
>> Changes in v2:
>> - Pick up tags
>> - Fix a couple typos in commit messages
>> - Drop stray msm8998 binding addition
>> - Link to v1: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v1-0-50c60ffe1130@linaro.org
>>
>> ---
>> Konrad Dybcio (2):
>> dt-bindings: thermal: lmh: Add QCM2290 compatible
>> thermal: qcom: lmh: Check for SCM availability at probe
>>
>> Loic Poulain (1):
>> arm64: dts: qcom: qcm2290: Add LMH node
>>
>> Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
>> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
>> drivers/thermal/qcom/lmh.c | 3 +++
>> 3 files changed, 24 insertions(+), 5 deletions(-)
>
> Hi,
>
> I've started tracking the results of 'make dtbs_check' on linux-next, and I've
> noticed that on today's next, next-20240320, there's a new warning coming from
> this. The reason is that the DT change has landed, but the binding has not,
> since it goes through a separate tree. I thought the binding was supposed to
> always land before the driver and DT that make use of it, but looking through
> the dt-binding documentation pages I couldn't find anything confirming or
> denying that.
Yes, that's the ideal way of things happening..
>
> I expect this to happen again in the future, which is why I'm reaching out to
> understand better how to deal with this kind of situation.
..but due to the kernel dev process, doing that across multiple trees would
either require constant agreements on immutable branches containing bindings,
mixing patches across trees, or delaying dts changes by a cycle or so
Konrad
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] QCM2290 LMH
2024-03-20 19:08 ` Nícolas F. R. A. Prado
2024-03-25 19:48 ` Konrad Dybcio
@ 2024-03-25 19:59 ` Krzysztof Kozlowski
2024-03-25 23:01 ` Nícolas F. R. A. Prado
1 sibling, 1 reply; 18+ messages in thread
From: Krzysztof Kozlowski @ 2024-03-25 19:59 UTC (permalink / raw
To: Nícolas F. R. A. Prado, Konrad Dybcio
Cc: Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thara Gopinath, Amit Kucheria, Marijn Suijten, linux-arm-msm,
linux-pm, devicetree, linux-kernel, Dmitry Baryshkov, stable,
Loic Poulain
On 20/03/2024 20:08, Nícolas F. R. A. Prado wrote:
>> Loic Poulain (1):
>> arm64: dts: qcom: qcm2290: Add LMH node
>>
>> Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
>> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
>> drivers/thermal/qcom/lmh.c | 3 +++
>> 3 files changed, 24 insertions(+), 5 deletions(-)
>
> Hi,
>
> I've started tracking the results of 'make dtbs_check' on linux-next, and I've
> noticed that on today's next, next-20240320, there's a new warning coming from
> this. The reason is that the DT change has landed, but the binding has not,
> since it goes through a separate tree. I thought the binding was supposed to
> always land before the driver and DT that make use of it, but looking through
There is no such rule. Of course new binding should be documented in
earlier or the same kernel release cycle as users get in, but it's not a
requirement.
> the dt-binding documentation pages I couldn't find anything confirming or
> denying that.
>
> I expect this to happen again in the future, which is why I'm reaching out to
> understand better how to deal with this kind of situation.
Deal as what to do? Are you asking in terms of maintenance of some
subsystem or sending some patches? In this particular case here, I don't
think there is anything on your side to deal with.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] QCM2290 LMH
2024-03-25 19:59 ` Krzysztof Kozlowski
@ 2024-03-25 23:01 ` Nícolas F. R. A. Prado
2024-03-26 6:29 ` Krzysztof Kozlowski
0 siblings, 1 reply; 18+ messages in thread
From: Nícolas F. R. A. Prado @ 2024-03-25 23:01 UTC (permalink / raw
To: Krzysztof Kozlowski
Cc: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thara Gopinath, Amit Kucheria, Marijn Suijten,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, stable, Loic Poulain
On Mon, Mar 25, 2024 at 08:59:55PM +0100, Krzysztof Kozlowski wrote:
> On 20/03/2024 20:08, Nícolas F. R. A. Prado wrote:
> >> Loic Poulain (1):
> >> arm64: dts: qcom: qcm2290: Add LMH node
> >>
> >> Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
> >> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
> >> drivers/thermal/qcom/lmh.c | 3 +++
> >> 3 files changed, 24 insertions(+), 5 deletions(-)
> >
> > Hi,
> >
> > I've started tracking the results of 'make dtbs_check' on linux-next, and I've
> > noticed that on today's next, next-20240320, there's a new warning coming from
> > this. The reason is that the DT change has landed, but the binding has not,
> > since it goes through a separate tree. I thought the binding was supposed to
> > always land before the driver and DT that make use of it, but looking through
>
> There is no such rule. Of course new binding should be documented in
> earlier or the same kernel release cycle as users get in, but it's not a
> requirement.
So, after giving the documentation a second look, I found this:
"For new platforms, or additions to existing ones, make dtbs_check should not
add any new warnings."
Source: https://www.kernel.org/doc/html/latest/process/maintainer-soc.html#validating-devicetree-files
What is not clear there is what the reference point is: is it on linux-next?
Mainline release?
As Konrad pointed out it's tricky (and maybe not worth it) to guarantee this for
linux-next. But for mainline release it seems feasible (and IMO the target, as
after that stability guarantees should apply).
>
>
> > the dt-binding documentation pages I couldn't find anything confirming or
> > denying that.
> >
> > I expect this to happen again in the future, which is why I'm reaching out to
> > understand better how to deal with this kind of situation.
>
> Deal as what to do? Are you asking in terms of maintenance of some
> subsystem or sending some patches? In this particular case here, I don't
> think there is anything on your side to deal with.
I'm asking what's the most helpful way to you the maintainers for me to report
these failures in the future.
Rob has already automated running dtbs_check for patches coming into the mailing
list. And I have set up KernelCI to run dtbs_check on linux-next in order to
catch any issues that might slip through, or happen during integration of the
trees, etc.
Now, if we agree that dtbs_check regressions on linux-next are acceptable, at
least ones like this, where the issue is just synchronization between
maintainers, then I can simply not report them in the future. But we should
have some point where dtbs_check should not regress, and mainline release seems
the reasonable choice, because if we don't then dtbs_check warnings would just
keep growing forever.
Thanks,
Nícolas
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] QCM2290 LMH
2024-03-25 23:01 ` Nícolas F. R. A. Prado
@ 2024-03-26 6:29 ` Krzysztof Kozlowski
2024-03-26 14:07 ` Nícolas F. R. A. Prado
0 siblings, 1 reply; 18+ messages in thread
From: Krzysztof Kozlowski @ 2024-03-26 6:29 UTC (permalink / raw
To: Nícolas F. R. A. Prado
Cc: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thara Gopinath, Amit Kucheria, Marijn Suijten,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, stable, Loic Poulain
On 26/03/2024 00:01, Nícolas F. R. A. Prado wrote:
> On Mon, Mar 25, 2024 at 08:59:55PM +0100, Krzysztof Kozlowski wrote:
>> On 20/03/2024 20:08, Nícolas F. R. A. Prado wrote:
>>>> Loic Poulain (1):
>>>> arm64: dts: qcom: qcm2290: Add LMH node
>>>>
>>>> Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
>>>> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
>>>> drivers/thermal/qcom/lmh.c | 3 +++
>>>> 3 files changed, 24 insertions(+), 5 deletions(-)
>>>
>>> Hi,
>>>
>>> I've started tracking the results of 'make dtbs_check' on linux-next, and I've
>>> noticed that on today's next, next-20240320, there's a new warning coming from
>>> this. The reason is that the DT change has landed, but the binding has not,
>>> since it goes through a separate tree. I thought the binding was supposed to
>>> always land before the driver and DT that make use of it, but looking through
>>
>> There is no such rule. Of course new binding should be documented in
>> earlier or the same kernel release cycle as users get in, but it's not a
>> requirement.
>
> So, after giving the documentation a second look, I found this:
>
> "For new platforms, or additions to existing ones, make dtbs_check should not
> add any new warnings."
>
> Source: https://www.kernel.org/doc/html/latest/process/maintainer-soc.html#validating-devicetree-files
It's just "should"...
>
> What is not clear there is what the reference point is: is it on linux-next?
> Mainline release?
Does it matter? There was never a new warning introduced by this
patchset. The patchset itself is correct. No new warnings.
>
> As Konrad pointed out it's tricky (and maybe not worth it) to guarantee this for
> linux-next. But for mainline release it seems feasible (and IMO the target, as
> after that stability guarantees should apply).
I don't believe in such guarantees. Different maintainers apply patches
differently, especially bindings, so this is beyond our control. Often
also beyond SoC maintainer control.
>
>>
>>
>>> the dt-binding documentation pages I couldn't find anything confirming or
>>> denying that.
>>>
>>> I expect this to happen again in the future, which is why I'm reaching out to
>>> understand better how to deal with this kind of situation.
>>
>> Deal as what to do? Are you asking in terms of maintenance of some
>> subsystem or sending some patches? In this particular case here, I don't
>> think there is anything on your side to deal with.
>
> I'm asking what's the most helpful way to you the maintainers for me to report
> these failures in the future.
The most effective way is LKP-like or Rob's-bot-like automated replies
to original email threads, by testing the original patchset on
linux-next. But Rob's bot is actually doing it, just on different base.
Other reports, like for cases when only parts of patch is applied, could
be also useful but I am afraid you will generate way too much of them.
Binding is supposed to go via subsystem, DTS via SoC, so basically 90%
of patchsets might have some sort of delays resulting in dtbs_check
false positive warnings.
For my SoC I check my trees, mainline and next, and keep adding list of
exceptions for expected issues. What's useful for Qualcomm? Konrad,
Bjorn, any thoughts?
Have in mind that expected warnings can be for entire cycle when dealing
with technical debt, because DTS goes N+1.
>
> Rob has already automated running dtbs_check for patches coming into the mailing
> list. And I have set up KernelCI to run dtbs_check on linux-next in order to
> catch any issues that might slip through, or happen during integration of the
> trees, etc.
>
> Now, if we agree that dtbs_check regressions on linux-next are acceptable, at
> least ones like this, where the issue is just synchronization between
Yes and no. True regressions are not acceptable. Expected intermediate
regressions as a result of patchset being applying, but not yet fully
applied, are OK. Expected regressions for intra-cycle-work are also OK.
> maintainers, then I can simply not report them in the future. But we should
> have some point where dtbs_check should not regress, and mainline release seems
> the reasonable choice, because if we don't then dtbs_check warnings would just
> keep growing forever.
I invite therefore to my session:
https://eoss24.sched.com/event/1aBEf?iframe=no
We'll see if they keep growing :)
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] QCM2290 LMH
2024-03-26 6:29 ` Krzysztof Kozlowski
@ 2024-03-26 14:07 ` Nícolas F. R. A. Prado
2024-03-27 4:04 ` Krzysztof Kozlowski
0 siblings, 1 reply; 18+ messages in thread
From: Nícolas F. R. A. Prado @ 2024-03-26 14:07 UTC (permalink / raw
To: Krzysztof Kozlowski
Cc: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thara Gopinath, Amit Kucheria, Marijn Suijten,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, stable, Loic Poulain
On Tue, Mar 26, 2024 at 07:29:17AM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 00:01, Nícolas F. R. A. Prado wrote:
> > On Mon, Mar 25, 2024 at 08:59:55PM +0100, Krzysztof Kozlowski wrote:
> >> On 20/03/2024 20:08, Nícolas F. R. A. Prado wrote:
> >>>> Loic Poulain (1):
> >>>> arm64: dts: qcom: qcm2290: Add LMH node
> >>>>
> >>>> Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
> >>>> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++-
> >>>> drivers/thermal/qcom/lmh.c | 3 +++
> >>>> 3 files changed, 24 insertions(+), 5 deletions(-)
> >>>
> >>> Hi,
> >>>
> >>> I've started tracking the results of 'make dtbs_check' on linux-next, and I've
> >>> noticed that on today's next, next-20240320, there's a new warning coming from
> >>> this. The reason is that the DT change has landed, but the binding has not,
> >>> since it goes through a separate tree. I thought the binding was supposed to
> >>> always land before the driver and DT that make use of it, but looking through
> >>
> >> There is no such rule. Of course new binding should be documented in
> >> earlier or the same kernel release cycle as users get in, but it's not a
> >> requirement.
> >
> > So, after giving the documentation a second look, I found this:
> >
> > "For new platforms, or additions to existing ones, make dtbs_check should not
> > add any new warnings."
> >
> > Source: https://www.kernel.org/doc/html/latest/process/maintainer-soc.html#validating-devicetree-files
>
> It's just "should"...
>
> >
> > What is not clear there is what the reference point is: is it on linux-next?
> > Mainline release?
>
> Does it matter? There was never a new warning introduced by this
> patchset. The patchset itself is correct. No new warnings.
>
> >
> > As Konrad pointed out it's tricky (and maybe not worth it) to guarantee this for
> > linux-next. But for mainline release it seems feasible (and IMO the target, as
> > after that stability guarantees should apply).
>
> I don't believe in such guarantees. Different maintainers apply patches
> differently, especially bindings, so this is beyond our control. Often
> also beyond SoC maintainer control.
>
> >
> >>
> >>
> >>> the dt-binding documentation pages I couldn't find anything confirming or
> >>> denying that.
> >>>
> >>> I expect this to happen again in the future, which is why I'm reaching out to
> >>> understand better how to deal with this kind of situation.
> >>
> >> Deal as what to do? Are you asking in terms of maintenance of some
> >> subsystem or sending some patches? In this particular case here, I don't
> >> think there is anything on your side to deal with.
> >
> > I'm asking what's the most helpful way to you the maintainers for me to report
> > these failures in the future.
>
> The most effective way is LKP-like or Rob's-bot-like automated replies
> to original email threads, by testing the original patchset on
> linux-next. But Rob's bot is actually doing it, just on different base.
>
> Other reports, like for cases when only parts of patch is applied, could
> be also useful but I am afraid you will generate way too much of them.
> Binding is supposed to go via subsystem, DTS via SoC, so basically 90%
> of patchsets might have some sort of delays resulting in dtbs_check
> false positive warnings.
>
> For my SoC I check my trees, mainline and next, and keep adding list of
> exceptions for expected issues. What's useful for Qualcomm? Konrad,
Is that list of exceptions in-tree? If there are known false-positives (issues
that can't be "properly" fixed), they should be public knowledge. And if we all
collaborate on such a list we can remove the noise from dtbs_check's output so
it only contains real regressions and a backlog of issues that can be fixed.
> Bjorn, any thoughts?
>
> Have in mind that expected warnings can be for entire cycle when dealing
> with technical debt, because DTS goes N+1.
>
> >
> > Rob has already automated running dtbs_check for patches coming into the mailing
> > list. And I have set up KernelCI to run dtbs_check on linux-next in order to
> > catch any issues that might slip through, or happen during integration of the
> > trees, etc.
> >
> > Now, if we agree that dtbs_check regressions on linux-next are acceptable, at
> > least ones like this, where the issue is just synchronization between
>
> Yes and no. True regressions are not acceptable. Expected intermediate
> regressions as a result of patchset being applying, but not yet fully
> applied, are OK. Expected regressions for intra-cycle-work are also OK.
Got it. So I'll keep KernelCI running dtbs_check and tracking it, but I won't
report failures caused by partially applied series.
>
> > maintainers, then I can simply not report them in the future. But we should
> > have some point where dtbs_check should not regress, and mainline release seems
> > the reasonable choice, because if we don't then dtbs_check warnings would just
> > keep growing forever.
>
> I invite therefore to my session:
> https://eoss24.sched.com/event/1aBEf?iframe=no
> We'll see if they keep growing :)
I won't be able to attend EOSS, but will catch the recording later ;)
Thanks,
Nícolas
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] QCM2290 LMH
2024-03-26 14:07 ` Nícolas F. R. A. Prado
@ 2024-03-27 4:04 ` Krzysztof Kozlowski
0 siblings, 0 replies; 18+ messages in thread
From: Krzysztof Kozlowski @ 2024-03-27 4:04 UTC (permalink / raw
To: Nícolas F. R. A. Prado
Cc: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thara Gopinath, Amit Kucheria, Marijn Suijten,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, stable, Loic Poulain
On 26/03/2024 15:07, Nícolas F. R. A. Prado wrote:
>> Other reports, like for cases when only parts of patch is applied, could
>> be also useful but I am afraid you will generate way too much of them.
>> Binding is supposed to go via subsystem, DTS via SoC, so basically 90%
>> of patchsets might have some sort of delays resulting in dtbs_check
>> false positive warnings.
>>
>> For my SoC I check my trees, mainline and next, and keep adding list of
>> exceptions for expected issues. What's useful for Qualcomm? Konrad,
>
> Is that list of exceptions in-tree? If there are known false-positives (issues
None of the warnings - C, sparse, smatch, coccinelle, Coverity, dtc,
dtbs_check - are stored in-tree. I don't think dtbs_check should be here
exception, because all these warnings can be fixed - it's just a matter
of effort. ARM64 Exynos is warning free since a year. ARM Exynos
similarly, but with one undocumented compatible and few bumps due to
intra-cycle DTS changes.
> that can't be "properly" fixed), they should be public knowledge. And if we all
They are "public":
https://github.com/krzk/tools/blob/master/buildbot/master_build_common.py#L26
but I don't know how to make them public and usable knowledge.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 18+ messages in thread
* [thermal: thermal/fixes] thermal/drivers/qcom/lmh: Check for SCM availability at probe
2024-03-09 13:15 ` [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe Konrad Dybcio
2024-03-18 1:27 ` Bjorn Andersson
2024-03-21 17:13 ` Daniel Lezcano
@ 2024-05-14 10:18 ` thermal-bot for Konrad Dybcio
2 siblings, 0 replies; 18+ messages in thread
From: thermal-bot for Konrad Dybcio @ 2024-05-14 10:18 UTC (permalink / raw
To: linux-pm
Cc: stable, Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio,
Daniel Lezcano, rui.zhang, amitk
The following commit has been merged into the thermal/fixes branch of thermal:
Commit-ID: d9d3490c48df572edefc0b64655259eefdcbb9be
Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git//d9d3490c48df572edefc0b64655259eefdcbb9be
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
AuthorDate: Sat, 09 Mar 2024 14:15:03 +01:00
Committer: Daniel Lezcano <daniel.lezcano@linaro.org>
CommitterDate: Tue, 23 Apr 2024 12:40:29 +02:00
thermal/drivers/qcom/lmh: Check for SCM availability at probe
Up until now, the necessary scm availability check has not been
performed, leading to possible null pointer dereferences (which did
happen for me on RB1).
Fix that.
Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v2-2-bac3914b0fe3@linaro.org
---
drivers/thermal/qcom/lmh.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
index f6edb12..5225b36 100644
--- a/drivers/thermal/qcom/lmh.c
+++ b/drivers/thermal/qcom/lmh.c
@@ -95,6 +95,9 @@ static int lmh_probe(struct platform_device *pdev)
unsigned int enable_alg;
u32 node_id;
+ if (!qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
lmh_data = devm_kzalloc(dev, sizeof(*lmh_data), GFP_KERNEL);
if (!lmh_data)
return -ENOMEM;
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [thermal: thermal/fixes] dt-bindings: thermal: lmh: Add QCM2290 compatible
2024-03-09 13:15 ` [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible Konrad Dybcio
2024-03-10 8:49 ` Krzysztof Kozlowski
2024-03-21 17:13 ` Daniel Lezcano
@ 2024-05-14 10:18 ` thermal-bot for Konrad Dybcio
2 siblings, 0 replies; 18+ messages in thread
From: thermal-bot for Konrad Dybcio @ 2024-05-14 10:18 UTC (permalink / raw
To: linux-pm
Cc: Konrad Dybcio, Krzysztof Kozlowski, Daniel Lezcano, rui.zhang,
amitk
The following commit has been merged into the thermal/fixes branch of thermal:
Commit-ID: c0f14ec95262cdcf557016f84b87e45f54e0b881
Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git//c0f14ec95262cdcf557016f84b87e45f54e0b881
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
AuthorDate: Sat, 09 Mar 2024 14:15:02 +01:00
Committer: Daniel Lezcano <daniel.lezcano@linaro.org>
CommitterDate: Tue, 23 Apr 2024 12:40:29 +02:00
dt-bindings: thermal: lmh: Add QCM2290 compatible
Document the QCM2290 LMH.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v2-1-bac3914b0fe3@linaro.org
---
Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 +++++---
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
index 5ff72ce..1175bb3 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
@@ -17,10 +17,14 @@ description:
properties:
compatible:
- enum:
- - qcom,sc8180x-lmh
- - qcom,sdm845-lmh
- - qcom,sm8150-lmh
+ oneOf:
+ - enum:
+ - qcom,sc8180x-lmh
+ - qcom,sdm845-lmh
+ - qcom,sm8150-lmh
+ - items:
+ - const: qcom,qcm2290-lmh
+ - const: qcom,sm8150-lmh
reg:
items:
^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2024-05-14 10:19 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-09 13:15 [PATCH v2 0/3] QCM2290 LMH Konrad Dybcio
2024-03-09 13:15 ` [PATCH v2 1/3] dt-bindings: thermal: lmh: Add QCM2290 compatible Konrad Dybcio
2024-03-10 8:49 ` Krzysztof Kozlowski
2024-03-21 17:13 ` Daniel Lezcano
2024-05-14 10:18 ` [thermal: thermal/fixes] " thermal-bot for Konrad Dybcio
2024-03-09 13:15 ` [PATCH v2 2/3] thermal: qcom: lmh: Check for SCM availability at probe Konrad Dybcio
2024-03-18 1:27 ` Bjorn Andersson
2024-03-21 17:13 ` Daniel Lezcano
2024-05-14 10:18 ` [thermal: thermal/fixes] thermal/drivers/qcom/lmh: " thermal-bot for Konrad Dybcio
2024-03-09 13:15 ` [PATCH v2 3/3] arm64: dts: qcom: qcm2290: Add LMH node Konrad Dybcio
2024-03-19 2:48 ` (subset) [PATCH v2 0/3] QCM2290 LMH Bjorn Andersson
2024-03-20 19:08 ` Nícolas F. R. A. Prado
2024-03-25 19:48 ` Konrad Dybcio
2024-03-25 19:59 ` Krzysztof Kozlowski
2024-03-25 23:01 ` Nícolas F. R. A. Prado
2024-03-26 6:29 ` Krzysztof Kozlowski
2024-03-26 14:07 ` Nícolas F. R. A. Prado
2024-03-27 4:04 ` Krzysztof Kozlowski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.