[PATCH PREVIEW v2 0/2] Add support tsens in ipq5210 & ipq9650

[PATCH PREVIEW v2 0/2] Add support tsens in ipq5210 & ipq9650

[Varadarajan Narayanan]

ipq5210 and ipq9560 have the Qualcomm tsens-v2 IP. The tsens framework
in these two SoCs are similar to the one found in ipq5332. This series
adds the sensor data to the tsens-v2 driver.

v2: Combine bindings and driver patches
    Use fallback for ipq5210 and dropped the driver changes

v1: bindings - https://lore.kernel.org/linux-arm-msm/20260515-tsens-yaml-v1-1-8039c62cc249@oss.qualcomm.com/
    driver - https://lore.kernel.org/linux-arm-msm/20260515-tsens-driver-v1-0-015ca76f1418@oss.qualcomm.com/

Varadarajan Narayanan (2):
  dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible
  thermal/drivers/qcom/tsens: Add support for ipq9650 tsens

 Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 7 +++++++
 drivers/thermal/qcom/tsens-v2.c                           | 8 ++++++++
 drivers/thermal/qcom/tsens.c                              | 3 +++
 drivers/thermal/qcom/tsens.h                              | 2 +-
 4 files changed, 19 insertions(+), 1 deletion(-)

-- 
2.34.1

[PATCH v2 1/2] dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible

[Varadarajan Narayanan]

Add the compatible for the thermal sensors on the ipq5210 and ipq9650. The
ipq5210 uses ipq5332-tsens as a fallback, while ipq9650 is added as a
standalone v2 TSENS compatible with combined interrupt.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
v2: Fix fallback definition
---
 Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index 7d34ba00e684..a927650c119b 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -92,6 +92,13 @@ properties:
           - qcom,ipq5332-tsens
           - qcom,ipq5424-tsens
           - qcom,ipq8074-tsens
+          - qcom,ipq9650-tsens
+
+      - description: v2 of TSENS with combined interrupt
+        items:
+          - enum:
+              - qcom,ipq5210-tsens
+          - const: qcom,ipq5332-tsens
 
       - description: v2 of TSENS with combined interrupt
         items:
-- 
2.34.1

Re: [PATCH v2 1/2] dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing schema validation constraints for `qcom,ipq9650-tsens` due to omitted compatible string in `allOf` conditional blocks.
--

commit 4b153774882bf21dfe2ec762bc94eb3a253bf2ac
Author: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible

Add the compatible for the thermal sensors on the ipq5210 and ipq9650. The
ipq5210 uses ipq5332-tsens as a fallback, while ipq9650 is added as a
standalone v2 TSENS compatible with combined interrupt.

> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> index 7d34ba00e684f..a927650c119b9 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> @@ -92,6 +92,13 @@ properties:
>            - qcom,ipq5332-tsens
>            - qcom,ipq5424-tsens
>            - qcom,ipq8074-tsens
> +          - qcom,ipq9650-tsens

[Severity: Medium]
Should qcom,ipq9650-tsens also be added to the allOf conditional blocks that
enforce constraints for related TSENS v2 hardware?

The commit message mentions this is a v2 TSENS compatible with a combined
interrupt. However, it appears the compatible string was omitted from the
if-then blocks further down in the schema.

For example, the conditional that enforces interrupt-names must be 'combined'
currently checks:

  - if:
      properties:
        compatible:
          contains:
            enum:
              - qcom,ipq5332-tsens
              - qcom,ipq5424-tsens
              - qcom,ipq8074-tsens

Similarly, the conditional that enforces the reg property is strictly required
for v2 variants omits qcom,ipq9650-tsens.

Without being added to those conditional blocks, won't nodes using
qcom,ipq9650-tsens silently pass dt_binding_check validation even if they omit
the reg property or have incorrect interrupt-names?

> +
> +      - description: v2 of TSENS with combined interrupt
> +        items:
> +          - enum:
> +              - qcom,ipq5210-tsens
> +          - const: qcom,ipq5332-tsens
>  
>        - description: v2 of TSENS with combined interrupt
>          items:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609065447.4024695-1-varadarajan.narayanan@oss.qualcomm.com?part=1

[PATCH v2 2/2] thermal/drivers/qcom/tsens: Add support for ipq9650 tsens

[Varadarajan Narayanan]

ipq9650's tsens is similar to ipq5332 tsens but has different number of
sensors. Re-use the ipq5332 data for ipq9650 and modify the sensor related
information.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 drivers/thermal/qcom/tsens-v2.c | 8 ++++++++
 drivers/thermal/qcom/tsens.c    | 3 +++
 drivers/thermal/qcom/tsens.h    | 2 +-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index 8d9698ea3ec4..ef1fee2266a3 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -300,6 +300,14 @@ const struct tsens_plat_data data_ipq5424 = {
 	.fields		= tsens_v2_regfields,
 };
 
+const struct tsens_plat_data data_ipq9650 = {
+	.num_sensors	= 11,
+	.ops		= &ops_ipq5332,
+	.hw_ids		= (unsigned int []){5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15},
+	.feat		= &ipq5332_feat,
+	.fields		= tsens_v2_regfields,
+};
+
 /* Kept around for backward compatibility with old msm8996.dtsi */
 struct tsens_plat_data data_8996 = {
 	.num_sensors	= 13,
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index a2422ebee816..e7bc622891ca 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -1122,6 +1122,9 @@ static const struct of_device_id tsens_table[] = {
 	}, {
 		.compatible = "qcom,ipq8074-tsens",
 		.data = &data_ipq8074,
+	}, {
+		.compatible = "qcom,ipq9650-tsens",
+		.data = &data_ipq9650,
 	}, {
 		.compatible = "qcom,mdm9607-tsens",
 		.data = &data_9607,
diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index 2a7afa4c899b..d9d50d32c962 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -657,6 +657,6 @@ extern const struct tsens_plat_data data_ipq5018;
 
 /* TSENS v2 targets */
 extern struct tsens_plat_data data_8996, data_ipq8074, data_tsens_v2;
-extern const struct tsens_plat_data data_ipq5332, data_ipq5424;
+extern const struct tsens_plat_data data_ipq5332, data_ipq5424, data_ipq9650;
 
 #endif /* __QCOM_TSENS_H__ */
-- 
2.34.1

Re: [PATCH v2 2/2] thermal/drivers/qcom/tsens: Add support for ipq9650 tsens

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The device tree property `#qcom,sensors` can override `num_sensors`, leading to an out-of-bounds read of the static `hw_ids` array and subsequent out-of-bounds array accesses.
--

commit 1557d45f1d577e6cb959599793cf39e4448627b6
Author: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

thermal/drivers/qcom/tsens: Add support for ipq9650 tsens

This commit adds support for the ipq9650 tsens device by reusing the
ipq5332 ops and features, while defining a custom hardware ID array for
its 11 sensors.

> diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
> index 8d9698ea3ec40..ef1fee2266a32 100644
> --- a/drivers/thermal/qcom/tsens-v2.c
> +++ b/drivers/thermal/qcom/tsens-v2.c
> @@ -300,6 +300,14 @@ const struct tsens_plat_data data_ipq5424 = {
>  	.fields		= tsens_v2_regfields,
>  };
>  
> +const struct tsens_plat_data data_ipq9650 = {
> +	.num_sensors	= 11,
> +	.ops		= &ops_ipq5332,
> +	.hw_ids		= (unsigned int []){5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15},

[Severity: High]
This is a pre-existing issue, but does this hardcoded array expose us to
an out-of-bounds read if the device tree overrides the number of sensors?

In drivers/thermal/qcom/tsens.c:tsens_probe(), the number of sensors can
be overridden by the #qcom,sensors DT property. The probe function later
initializes the sensors in a loop:

    for (i = 0;  i < priv->num_sensors; i++) {
        if (data->hw_ids)
            priv->sensor[i].hw_id = data->hw_ids[i];
        else
            priv->sensor[i].hw_id = i;
    }

If a device tree specifies a larger number of sensors than the length of
this new array (for example 12, which is under the MAX_SENSORS limit of 16),
will the initialization loop read past the end of the hw_ids array?

It looks like this could result in garbage values being stored as hw_id,
which are then used as offsets for the fixed-size priv->rf[] regmap field
array, potentially causing arbitrary out-of-bounds pointer dereferences.

> +	.feat		= &ipq5332_feat,
> +	.fields		= tsens_v2_regfields,
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609065447.4024695-1-varadarajan.narayanan@oss.qualcomm.com?part=2