[PATCH v2 0/4] thermal: loongson2: Add support for Loongson-2K0300 SoC

[PATCH v2 0/4] thermal: loongson2: Add support for Loongson-2K0300 SoC

[Binbin Zhou]

Hi all:

This patch series adds thermal zone support for the Loongson-2K0300 SoC.

The Loongson-2K0300's thermal sensor is generally compatible with the
existing Loongson-2K series, but it features several key differences:
1. It has an independent CPU ID register for reading chip version
information.
2. The raw temperature output field has been extended from 8 bits to 11
bits.
3. The temperature calculation formula has been updated to incorporate a
correction factor based on the version information.

To ensure robustness on older hardware revisions, a fallback mechanism
is included: if the calculated temperature falls outside the valid range
(-55 TO 125),  the driver falls back to a simpler calculation and prints
a warning.

The patches have been validated on the Loongson-2K0300 development board.

Thanks.
Binbin

=========
V2:
Patch (1/4):
 - New patch form Sashiko;
Patch (2/4):
 - New patch for adding chipid syscon compatible;
Patch (3/4):
 - Use `loongson,chipid` phandle replace chipid reg property;
Patch (3/4):
 - Refact `calib_offset` calculate routing;
 - Add LS2K0300_OLD_FUSE_FLAG flag.

Link to V1:
https://lore.kernel.org/all/cover.1783670011.git.zhoubinbin@loongson.cn/

Binbin Zhou (4):
  thermal/drivers/loongson2: Correct thermal sensor registration loop
  dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300
    chip id
  dt-bindings: thermal: loongson,ls2k-thermal: Add compatible for
    Loongson-2K0300
  thermal/drivers/loongson2: Add support for Loongson-2K0300

 .../devicetree/bindings/mfd/syscon.yaml       |   2 +
 .../thermal/loongson,ls2k-thermal.yaml        |  73 ++++++++---
 drivers/thermal/loongson2_thermal.c           | 120 +++++++++++++++---
 3 files changed, 162 insertions(+), 33 deletions(-)

-- 
2.52.0

[PATCH v2 1/4] thermal/drivers/loongson2: Correct thermal sensor registration loop

[Binbin Zhou]

The registration loop in loongson2_thermal_probe() incorrectly uses
dev_err_probe() when the sensor is not present (-ENODEV). In that case,
the driver should continue to the next sensor index rather than treating
it as a fatal error.

Fix this by correctly handling -ENODEV and only returning on other
errors. Also add a final check to ensure at least one thermal zone was
registered.

Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/cover.1783670011.git.zhoubinbin@loongson.cn?part=2
Fixes: e7e3a7c35791 ("thermal/drivers/loongson-2: Add thermal management support")
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
 drivers/thermal/loongson2_thermal.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/loongson2_thermal.c b/drivers/thermal/loongson2_thermal.c
index ea4dd2fb1f47..d7d221c3136d 100644
--- a/drivers/thermal/loongson2_thermal.c
+++ b/drivers/thermal/loongson2_thermal.c
@@ -161,16 +161,18 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
 
 	for (i = 0; i <= LOONGSON2_MAX_SENSOR_SEL_NUM; i++) {
 		tzd = devm_thermal_of_zone_register(dev, i, data, thermal_ops);
-
 		if (!IS_ERR(tzd))
 			break;
 
-		if (PTR_ERR(tzd) != -ENODEV)
+		if (PTR_ERR(tzd) == -ENODEV)
 			continue;
 
-		return dev_err_probe(dev, PTR_ERR(tzd), "failed to register");
+		return dev_err_probe(dev, PTR_ERR(tzd), "failed to register sensor %d", i);
 	}
 
+	if (IS_ERR(tzd))
+		return dev_err_probe(dev, -ENODEV, "No thermal sensor registered\n");
+
 	ret = devm_request_threaded_irq(dev, irq, NULL, loongson2_thermal_irq_thread,
 					IRQF_ONESHOT, "loongson2_thermal", tzd);
 	if (ret < 0)
-- 
2.52.0

Re: [PATCH v2 1/4] thermal/drivers/loongson2: Correct thermal sensor registration loop

[sashiko-bot]

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

Pre-existing issues:
- [High] NULL Pointer Dereference via sysfs bind
- [Medium] Hardware Configuration Mismatch
- [Medium] Missing Teardown / Resource Leak
--

--- Patch [1]: [PATCH v2 1/4] thermal/drivers/loongson2: Correct thermal sensor registration loop ---
commit 381cd9ed04934716b53c8748d5c522210d6b54ff
Author: Binbin Zhou <zhoubinbin@loongson.cn>

thermal/drivers/loongson2: Correct thermal sensor registration loop

The registration loop in loongson2_thermal_probe() incorrectly uses
dev_err_probe() when the sensor is not present (-ENODEV). Fix this by
correctly handling -ENODEV and only returning on other errors.

Closes: https://sashiko.dev/#/patchset/cover.1783670011.git.zhoubinbin@loongson.cn?part=2

> diff --git a/drivers/thermal/loongson2_thermal.c b/drivers/thermal/loongson2_thermal.c
> index ea4dd2fb1f473..d7d221c3136d4 100644
> --- a/drivers/thermal/loongson2_thermal.c
> +++ b/drivers/thermal/loongson2_thermal.c
> @@ -161,16 +161,18 @@ static int loongson2_thermal_probe(struct platform_device *pdev)

[Severity: High]
This is a pre-existing issue, but does device_get_match_data() return NULL
when binding the driver via sysfs to a platform device that lacks OF match
data?

In loongson2_thermal_probe(), data->chip_data is assigned from
device_get_match_data(dev) and then immediately dereferenced:

    data->chip_data = device_get_match_data(dev);
    ...
    if (data->chip_data->flags & LS2K2000_THSENS_OUT_FLAG) {

Could this cause a NULL pointer dereference crash if bound by name via sysfs?

>  
>  	for (i = 0; i <= LOONGSON2_MAX_SENSOR_SEL_NUM; i++) {
>  		tzd = devm_thermal_of_zone_register(dev, i, data, thermal_ops);
> -
>  		if (!IS_ERR(tzd))
>  			break;

[Severity: Medium]
This is a pre-existing issue, but does this code properly save the
discovered sensor index?

If the device tree specifies a non-zero sensor index, the actual sensor
index is discovered here but then discarded instead of being saved to
the instance data.

Later in loongson2_set_ctrl_regs(), the hardware register offset is
calculated using the hardcoded static match data rather than the index
actually discovered:

    int reg_off  = data->chip_data->thermal_sensor_sel * 2;

Could this cause the driver to report temperatures or configure thresholds
for the wrong hardware sensor (sensor 0) if the device tree specifies a
different index?

[ ... ]

> +	if (IS_ERR(tzd))
> +		return dev_err_probe(dev, -ENODEV, "No thermal sensor registered\n");
> +
>  	ret = devm_request_threaded_irq(dev, irq, NULL, loongson2_thermal_irq_thread,
>  					IRQF_ONESHOT, "loongson2_thermal", tzd);

[Severity: Medium]
This is a pre-existing issue, but is there a missing teardown for the
hardware interrupt state?

The probe function relies solely on devres for cleanup, but it does not
register a devm action to revert the hardware interrupt state initialized
by the thermal core:

    loongson2_thermal_set(data, 0, 0, false);

If the driver is manually unbound via sysfs or the module is unloaded, could
this leave the device actively asserting its interrupt line?

>  	if (ret < 0)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784619512.git.zhoubinbin@loongson.cn?part=1

[PATCH v2 2/4] dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id

[Binbin Zhou]

The Loongson-2K0300 SoC exposes its chip ID registers through a syscon
interface. Add the specific compatible `loongson,ls2k0300-chipid-syscon`
to the allowed list of syscon bindings so that it can be referenced from
the thermal node via a phandle.

Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
 Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index e22867088063..c5b2e28f6ced 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -76,6 +76,7 @@ select:
           - hpe,gxp-sysreg
           - loongson,ls1b-syscon
           - loongson,ls1c-syscon
+          - loongson,ls2k0300-cphipid-syscon
           - lsi,axxia-syscon
           - marvell,armada-3700-cpu-misc
           - marvell,armada-3700-nb-pm
@@ -189,6 +190,7 @@ properties:
               - hpe,gxp-sysreg
               - loongson,ls1b-syscon
               - loongson,ls1c-syscon
+              - loongson,ls2k0300-cphipid-syscon
               - lsi,axxia-syscon
               - marvell,armada-3700-cpu-misc
               - marvell,armada-3700-nb-pm
-- 
2.52.0

Re: [PATCH v2 2/4] dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The compatible string added in the patch contains a typographical error ('cphipid' instead of 'chipid').
--

--- Patch [2]: [PATCH v2 2/4] dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id ---
commit 5db600cb90f648eab2d8d155fce1a1ef7e8cd50e
Author: Binbin Zhou <zhoubinbin@loongson.cn>

dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id

The Loongson-2K0300 SoC exposes its chip ID registers through a syscon
interface. This commit adds a specific compatible string to the syscon
bindings list so it can be referenced by a phandle.

> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index e228670880631..c5b2e28f6cedd 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -76,6 +76,7 @@ select:
>            - hpe,gxp-sysreg
>            - loongson,ls1b-syscon
>            - loongson,ls1c-syscon
> +          - loongson,ls2k0300-cphipid-syscon

[Severity: Medium]
Is this spelling correct? The commit message mentions the compatible string
should be "loongson,ls2k0300-chipid-syscon", but this adds "cphipid" instead.
Will this cause schema validation to fail for device trees using the correctly
spelled chipid string?

>            - lsi,axxia-syscon
>            - marvell,armada-3700-cpu-misc
>            - marvell,armada-3700-nb-pm
[ ... ]
> @@ -189,6 +190,7 @@ properties:
>                - hpe,gxp-sysreg
>                - loongson,ls1b-syscon
>                - loongson,ls1c-syscon
> +              - loongson,ls2k0300-cphipid-syscon

[Severity: Medium]
Does this also contain the same "cphipid" typo as the select block above?

>                - lsi,axxia-syscon
>                - marvell,armada-3700-cpu-misc
>                - marvell,armada-3700-nb-pm

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784619512.git.zhoubinbin@loongson.cn?part=2

Re: [PATCH v2 2/4] dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On Tue, Jul 21, 2026 at 08:24:21PM +0800, Binbin Zhou wrote:
> The Loongson-2K0300 SoC exposes its chip ID registers through a syscon
> interface. Add the specific compatible `loongson,ls2k0300-chipid-syscon`
> to the allowed list of syscon bindings so that it can be referenced from
> the thermal node via a phandle.
> 
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
>  Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index e22867088063..c5b2e28f6ced 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -76,6 +76,7 @@ select:
>            - hpe,gxp-sysreg
>            - loongson,ls1b-syscon
>            - loongson,ls1c-syscon
> +          - loongson,ls2k0300-cphipid-syscon

You've spelt both of these wrong, "cphip" instead of "chip".

pw-bot: changes-requested

Thanks,
Conor.

>            - lsi,axxia-syscon
>            - marvell,armada-3700-cpu-misc
>            - marvell,armada-3700-nb-pm
> @@ -189,6 +190,7 @@ properties:
>                - hpe,gxp-sysreg
>                - loongson,ls1b-syscon
>                - loongson,ls1c-syscon
> +              - loongson,ls2k0300-cphipid-syscon
>                - lsi,axxia-syscon
>                - marvell,armada-3700-cpu-misc
>                - marvell,armada-3700-nb-pm
> -- 
> 2.52.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v2 3/4] dt-bindings: thermal: loongson,ls2k-thermal: Add compatible for Loongson-2K0300

[Binbin Zhou]

Add a new compatible string `loongson,ls2k0300-thermal` for the thermal
sensor found on the Loongson-2K0300 SoC.

The hardware differs from existing SoCs in that it requires a phandle to
a syscon node that provides the CHIP ID register, used as a compensation
source in the temperature calculation.

Update the binding to make `loongson,chipid` required for this new
compatible, and clarify the register region requirements for each
variant.

Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
 .../thermal/loongson,ls2k-thermal.yaml        | 73 ++++++++++++++-----
 1 file changed, 55 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
index 79e691b08341..d312e27737a2 100644
--- a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
@@ -10,13 +10,11 @@ maintainers:
   - zhanghongchen <zhanghongchen@loongson.cn>
   - Yinbo Zhu <zhuyinbo@loongson.cn>
 
-allOf:
-  - $ref: /schemas/thermal/thermal-sensor.yaml#
-
 properties:
   compatible:
     oneOf:
       - enum:
+          - loongson,ls2k0300-thermal
           - loongson,ls2k1000-thermal
           - loongson,ls2k2000-thermal
       - items:
@@ -34,28 +32,56 @@ properties:
   '#thermal-sensor-cells':
     const: 1
 
+  loongson,chipid:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      Phandle to the syscon with the Loongson-2K0300 CHIP ID.
+
 required:
   - compatible
   - reg
   - interrupts
 
-if:
-  properties:
-    compatible:
-      contains:
-        enum:
-          - loongson,ls2k2000-thermal
+allOf:
+  - $ref: /schemas/thermal/thermal-sensor.yaml#
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: loongson,ls2k0300-thermal
+    then:
+      properties:
+        reg:
+          items:
+            - description: Thermal base register region
+      required:
+        - loongson,chipid
 
-then:
-  properties:
-    reg:
-      minItems: 2
-      maxItems: 2
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: loongson,ls2k1000-thermal
+    then:
+      properties:
+        loongson,chipid: false
+        reg:
+          items:
+            - description: Thermal base register region
 
-else:
-  properties:
-    reg:
-      maxItems: 1
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: loongson,ls2k2000-thermal
+    then:
+      properties:
+        loongson,chipid: false
+        reg:
+          items:
+            - description: Thermal base register region
+            - description: Thermal data output register region
 
 unevaluatedProperties: false
 
@@ -69,3 +95,14 @@ examples:
         interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
         #thermal-sensor-cells = <1>;
     };
+
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    thermal-sensor@16001500 {
+       compatible = "loongson,ls2k0300-thermal";
+       reg = <0x16001500 0x30>;
+       interrupt-parent = <&liointc1>;
+       interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+       loongson,chipid = <&chipid>;
+       #thermal-sensor-cells = <1>;
+    };
-- 
2.52.0

Re: [PATCH v2 3/4] dt-bindings: thermal: loongson,ls2k-thermal: Add compatible for Loongson-2K0300

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `reg` property loses its strict size constraints for different variants because the explicit `minItems` and `maxItems` bounds were replaced by `items` descriptions inside the `if/then` blocks without restricting the array length.
- [Medium] The compatible string added to the syscon schema contains a typo (`cphipid` instead of `chipid`).
--

--- Patch [3]: [PATCH v2 3/4] dt-bindings: thermal: loongson,ls2k-thermal: Add compatible for Loongson-2K0300 ---
commit 685d641d1fef4db6e1df5ead93f5d8354f9d319d
Author: Binbin Zhou <zhoubinbin@loongson.cn>

dt-bindings: thermal: loongson,ls2k-thermal: Add compatible for Loongson-2K0300

This commit adds a new compatible string loongson,ls2k0300-thermal for the
thermal sensor on the Loongson-2K0300 SoC. It updates the binding to make
loongson,chipid required for this new compatible and restructures the register
region constraints for each variant.

> diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
> index 79e691b08341c..d312e27737a20 100644
> --- a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml

[ ... ]

> @@ -34,28 +32,56 @@ properties:
>    '#thermal-sensor-cells':
>      const: 1
>  
> +  loongson,chipid:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      Phandle to the syscon with the Loongson-2K0300 CHIP ID.
> +

[Severity: Medium]
It appears the compatible string added to the syscon schema for this device
contains a typo: loongson,ls2k0300-cphipid-syscon instead of chipid.

Documentation/devicetree/bindings/mfd/syscon.yaml:
          - loongson,ls1b-syscon
          - loongson,ls1c-syscon
          - loongson,ls2k0300-cphipid-syscon

Given the loongson,chipid property name here and the commit message referencing 
the chip id, was the cphipid spelling in syscon.yaml unintended?

>  required:
>    - compatible
>    - reg
>    - interrupts
>  
> -if:
> -  properties:
> -    compatible:
> -      contains:
> -        enum:
> -          - loongson,ls2k2000-thermal
> +allOf:
> +  - $ref: /schemas/thermal/thermal-sensor.yaml#
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: loongson,ls2k0300-thermal
> +    then:
> +      properties:
> +        reg:
> +          items:
> +            - description: Thermal base register region

[Severity: Medium]
Does removing the explicit maxItems: 1 constraint here cause a regression where
the reg property loses its strict size limits?

In JSON Schema and dt-schema, specifying items inside an if/then/properties
block does not restrict the maximum array length unless maxItems is explicitly
defined. Since the root level allows reg: maxItems: 2, will this configuration
mistakenly accept up to two register regions for loongson,ls2k0300-thermal?

> +      required:
> +        - loongson,chipid
>  
> -then:
> -  properties:
> -    reg:
> -      minItems: 2
> -      maxItems: 2
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: loongson,ls2k1000-thermal
> +    then:
> +      properties:
> +        loongson,chipid: false
> +        reg:
> +          items:
> +            - description: Thermal base register region

[Severity: Medium]
Similarly, does this block also need maxItems: 1 to prevent
loongson,ls2k1000-thermal from accepting two register regions?

>  
> -else:
> -  properties:
> -    reg:
> -      maxItems: 1
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: loongson,ls2k2000-thermal
> +    then:
> +      properties:
> +        loongson,chipid: false
> +        reg:
> +          items:
> +            - description: Thermal base register region
> +            - description: Thermal data output register region

[Severity: Medium]
The previous schema explicitly enforced lengths for loongson,ls2k2000-thermal
by stating minItems: 2 and maxItems: 2.

Without minItems: 2 here, will dt-schema now accept an incomplete single
register region for loongson,ls2k2000-thermal?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784619512.git.zhoubinbin@loongson.cn?part=3

Re: [PATCH v2 3/4] dt-bindings: thermal: loongson,ls2k-thermal: Add compatible for Loongson-2K0300

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v2 4/4] thermal/drivers/loongson2: Add support for Loongson-2K0300

[Binbin Zhou]

Add support for the thermal sensor found on the Loongson-2K0300 SoC.

The Loongson-2K0300 thermal sensor uses a 10-bit ADC and requires
per-chip calibration. The calibration offset is stored in the CHIP ID
registers, which are accessed via syscon. The driver reads this offset
and applies it when converting the raw ADC value to millicelsius.

To handle old fuse versions that cannot be calibrated correctly, the
driver includes a fallback formula and a validity check. Once invalid
data is detected, the driver falls back to the old formula for future
reads and warns the user.

Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
 drivers/thermal/loongson2_thermal.c | 112 +++++++++++++++++++++++++---
 1 file changed, 100 insertions(+), 12 deletions(-)

diff --git a/drivers/thermal/loongson2_thermal.c b/drivers/thermal/loongson2_thermal.c
index d7d221c3136d..e8d11e592a1f 100644
--- a/drivers/thermal/loongson2_thermal.c
+++ b/drivers/thermal/loongson2_thermal.c
@@ -2,9 +2,11 @@
 /*
  * Author: zhanghongchen <zhanghongchen@loongson.cn>
  *         Yinbo Zhu <zhuyinbo@loongson.cn>
- * Copyright (C) 2022-2023 Loongson Technology Corporation Limited
+ *         Binbin Zhou <zhoubinbin@loongson.cn>
+ * Copyright (C) 2022-2026 Loongson Technology Corporation Limited
  */
 
+#include <linux/bitfield.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/minmax.h>
@@ -14,6 +16,9 @@
 #include <linux/property.h>
 #include <linux/thermal.h>
 #include <linux/units.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/syscore_ops.h>
 
 #include "thermal_hwmon.h"
 
@@ -23,28 +28,48 @@
 #define LOONGSON2_THSENS_CTRL_LOW_REG	0x8
 #define LOONGSON2_THSENS_STATUS_REG	0x10
 #define LOONGSON2_THSENS_OUT_REG	0x14
+#define LOONGSON2_THSENS_CFG_REG	0x18
 
 #define LOONGSON2_THSENS_INT_LO		BIT(0)
 #define LOONGSON2_THSENS_INT_HIGH	BIT(1)
 #define LOONGSON2_THSENS_INT_EN		(LOONGSON2_THSENS_INT_LO | \
 					 LOONGSON2_THSENS_INT_HIGH)
-#define LOONGSON2_THSENS_OUT_MASK	0xFF
+#define LOONGSON2_THSENS_OUT_8B_MASK	0xFF
+#define LOONGSON2_THSENS_OUT_10B_MASK	GENMASK(10, 0)
+
+#define LS2K0300_CHIP_ID0		0x10
+#define LS2K0300_CHIP_ID1		0x14
+#define LS2K0300_EXTERN_ID		BIT(4)
+#define LS2K0300_ID0_VAL_MASK		GENMASK(31, 20)
+#define LS2K0300_ID1_VAL_MASK		GENMASK(15, 0)
+
+#define LS2K0300_COMP_VAL_MASK		GENMASK(14, 0)
+#define LS2K0300_COMP_SIGN_BIT		BIT(15)
+
+#define LS2K0300_LOWEST_VALID_TEMP	(-55000)
+#define LS2K0300_HIGHEST_VALID_TEMP	(125000)
 
 /*
  * This flag is used to indicate the temperature reading
  * method of the Loongson-2K2000
  */
 #define LS2K2000_THSENS_OUT_FLAG	BIT(0)
+#define LS2K0300_CHIP_ID_FLAG		BIT(1)
+#define LS2K0300_OLD_FUSE_FLAG		BIT(2)
 
 struct loongson2_thermal_chip_data {
 	unsigned int thermal_sensor_sel;
 	unsigned int flags;
+	const struct thermal_zone_device_ops *thermal_ops;
 };
 
 struct loongson2_thermal_data {
+	int calib_offset;
+	struct device *dev;
 	void __iomem *ctrl_reg;
 	void __iomem *temp_reg;
-	const struct loongson2_thermal_chip_data *chip_data;
+	struct regmap *regmap_cfg;
+	struct loongson2_thermal_chip_data *chip_data;
 };
 
 static void loongson2_set_ctrl_regs(struct loongson2_thermal_data *data,
@@ -71,13 +96,55 @@ static int loongson2_thermal_set(struct loongson2_thermal_data *data,
 	return 0;
 }
 
+static int loongson2_2k0300_get_temp(struct thermal_zone_device *tz, int *temp)
+{
+	struct loongson2_thermal_data *tdata = thermal_zone_device_priv(tz);
+	int calib_data, calib_offset, temp_mc, raw_adc;
+	u32 chip_id0, chip_id1;
+
+	writel(0xff03, tdata->ctrl_reg + LOONGSON2_THSENS_CFG_REG);
+	raw_adc = FIELD_GET(LOONGSON2_THSENS_OUT_10B_MASK,
+			    readl(tdata->ctrl_reg + LOONGSON2_THSENS_OUT_REG));
+
+	if (tdata->chip_data->flags & LS2K0300_OLD_FUSE_FLAG) {
+		*temp = raw_adc * 569 - 394700;
+		return 0;
+	}
+
+	regmap_read(tdata->regmap_cfg, LS2K0300_CHIP_ID0, &chip_id0);
+	regmap_read(tdata->regmap_cfg, LS2K0300_CHIP_ID1, &chip_id1);
+
+	if (chip_id0 & LS2K0300_EXTERN_ID) {
+		calib_data = FIELD_GET(LS2K0300_ID1_VAL_MASK, chip_id1);
+		calib_offset = FIELD_GET(LS2K0300_COMP_VAL_MASK, calib_data);
+		if (calib_data & LS2K0300_COMP_SIGN_BIT)
+			calib_offset = -calib_offset;
+	} else {
+		calib_data = FIELD_GET(LS2K0300_ID0_VAL_MASK, chip_id0);
+		calib_offset = FIELD_GET(LS2K0300_COMP_VAL_MASK, calib_data);
+	}
+
+	tdata->calib_offset = calib_offset;
+	temp_mc = (raw_adc + calib_offset) * 570 - 394700;
+
+	/* For old fuse which can not read right thermal data */
+	if (temp_mc < LS2K0300_LOWEST_VALID_TEMP || temp_mc > LS2K0300_HIGHEST_VALID_TEMP) {
+		dev_warn_once(tdata->dev, "It's an old fuse, thermal %d is not right\n", temp_mc);
+		tdata->chip_data->flags |= LS2K0300_OLD_FUSE_FLAG;
+		temp_mc = raw_adc * 569 - 394700;
+	}
+	*temp = temp_mc;
+
+	return 0;
+}
+
 static int loongson2_2k1000_get_temp(struct thermal_zone_device *tz, int *temp)
 {
 	int val;
 	struct loongson2_thermal_data *data = thermal_zone_device_priv(tz);
 
 	val = readl(data->ctrl_reg + LOONGSON2_THSENS_OUT_REG);
-	*temp = ((val & LOONGSON2_THSENS_OUT_MASK) - HECTO) * KILO;
+	*temp = ((val & LOONGSON2_THSENS_OUT_8B_MASK) - HECTO) * KILO;
 
 	return 0;
 }
@@ -112,6 +179,11 @@ static int loongson2_thermal_set_trips(struct thermal_zone_device *tz, int low,
 	return loongson2_thermal_set(data, low/MILLI, high/MILLI, true);
 }
 
+static const struct thermal_zone_device_ops loongson2_2k0300_of_thermal_ops = {
+	.get_temp = loongson2_2k0300_get_temp,
+	.set_trips = loongson2_thermal_set_trips,
+};
+
 static const struct thermal_zone_device_ops loongson2_2k1000_of_thermal_ops = {
 	.get_temp = loongson2_2k1000_get_temp,
 	.set_trips = loongson2_thermal_set_trips,
@@ -124,7 +196,6 @@ static const struct thermal_zone_device_ops loongson2_2k2000_of_thermal_ops = {
 
 static int loongson2_thermal_probe(struct platform_device *pdev)
 {
-	const struct thermal_zone_device_ops *thermal_ops;
 	struct device *dev = &pdev->dev;
 	struct loongson2_thermal_data *data;
 	struct thermal_zone_device *tzd;
@@ -134,7 +205,8 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
 	if (!data)
 		return -ENOMEM;
 
-	data->chip_data = device_get_match_data(dev);
+	data->dev = dev;
+	data->chip_data = (struct loongson2_thermal_chip_data *)device_get_match_data(dev);
 
 	data->ctrl_reg = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(data->ctrl_reg))
@@ -145,10 +217,14 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
 		data->temp_reg = devm_platform_ioremap_resource(pdev, 1);
 		if (IS_ERR(data->temp_reg))
 			return PTR_ERR(data->temp_reg);
+	}
 
-		thermal_ops = &loongson2_2k2000_of_thermal_ops;
-	} else {
-		thermal_ops = &loongson2_2k1000_of_thermal_ops;
+	/* The chip id register is needed for Loongson-2K0300 */
+	if (data->chip_data->flags & LS2K0300_CHIP_ID_FLAG) {
+		data->regmap_cfg =
+			syscon_regmap_lookup_by_phandle(dev->of_node, "loongson,chipid");
+		if (IS_ERR(data->regmap_cfg))
+			return PTR_ERR(data->regmap_cfg);
 	}
 
 	irq = platform_get_irq(pdev, 0);
@@ -160,7 +236,7 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
 	loongson2_thermal_set(data, 0, 0, false);
 
 	for (i = 0; i <= LOONGSON2_MAX_SENSOR_SEL_NUM; i++) {
-		tzd = devm_thermal_of_zone_register(dev, i, data, thermal_ops);
+		tzd = devm_thermal_of_zone_register(dev, i, data, data->chip_data->thermal_ops);
 		if (!IS_ERR(tzd))
 			break;
 
@@ -183,17 +259,29 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct loongson2_thermal_chip_data loongson2_thermal_ls2k1000_data = {
+static struct loongson2_thermal_chip_data loongson2_thermal_ls2k0300_data = {
+	.thermal_sensor_sel = 0,
+	.flags = LS2K0300_CHIP_ID_FLAG,
+	.thermal_ops = &loongson2_2k0300_of_thermal_ops,
+};
+
+static struct loongson2_thermal_chip_data loongson2_thermal_ls2k1000_data = {
 	.thermal_sensor_sel = 0,
 	.flags = 0,
+	.thermal_ops = &loongson2_2k1000_of_thermal_ops,
 };
 
-static const struct loongson2_thermal_chip_data loongson2_thermal_ls2k2000_data = {
+static struct loongson2_thermal_chip_data loongson2_thermal_ls2k2000_data = {
 	.thermal_sensor_sel = 0,
 	.flags = LS2K2000_THSENS_OUT_FLAG,
+	.thermal_ops = &loongson2_2k2000_of_thermal_ops,
 };
 
 static const struct of_device_id of_loongson2_thermal_match[] = {
+	{
+		.compatible = "loongson,ls2k0300-thermal",
+		.data = &loongson2_thermal_ls2k0300_data,
+	},
 	{
 		.compatible = "loongson,ls2k1000-thermal",
 		.data = &loongson2_thermal_ls2k1000_data,
-- 
2.52.0

Re: [PATCH v2 4/4] thermal/drivers/loongson2: Add support for Loongson-2K0300

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Global state mutation due to modifying shared match data.
- [High] Uninitialized stack variables used for critical temperature calculation due to ignored regmap_read() errors.
- [Medium] Off-by-one error in ADC bitmask definition results in an 11-bit mask for a 10-bit ADC.
- [Medium] Speculative: ADC configuration write is immediately followed by output read without hardware delay.
- [Low] Inefficient repeated fuse parsing and dead store of the calibration offset.
--

--- Patch [4]: [PATCH v2 4/4] thermal/drivers/loongson2: Add support for Loongson-2K0300 ---
commit 7a3c65aba38521ce4ea3dd10556d3932b4554449
Author: Binbin Zhou <zhoubinbin@loongson.cn>

thermal/drivers/loongson2: Add support for Loongson-2K0300
    
Add support for the thermal sensor found on the Loongson-2K0300 SoC.
The Loongson-2K0300 thermal sensor uses a 10-bit ADC and requires
per-chip calibration via syscon.

> diff --git a/drivers/thermal/loongson2_thermal.c b/drivers/thermal/loongson2_thermal.c
> index d7d221c3136d4..e8d11e592a1f2 100644
> --- a/drivers/thermal/loongson2_thermal.c
> +++ b/drivers/thermal/loongson2_thermal.c
[ ... ]
> @@ -23,28 +28,48 @@
>  #define LOONGSON2_THSENS_CTRL_LOW_REG	0x8
>  #define LOONGSON2_THSENS_STATUS_REG	0x10
>  #define LOONGSON2_THSENS_OUT_REG	0x14
> +#define LOONGSON2_THSENS_CFG_REG	0x18
>  
>  #define LOONGSON2_THSENS_INT_LO		BIT(0)
>  #define LOONGSON2_THSENS_INT_HIGH	BIT(1)
>  #define LOONGSON2_THSENS_INT_EN		(LOONGSON2_THSENS_INT_LO | \
>  					 LOONGSON2_THSENS_INT_HIGH)
> -#define LOONGSON2_THSENS_OUT_MASK	0xFF
> +#define LOONGSON2_THSENS_OUT_8B_MASK	0xFF
> +#define LOONGSON2_THSENS_OUT_10B_MASK	GENMASK(10, 0)

[Severity: Medium]
The commit message mentions a 10-bit ADC, but doesn't GENMASK(10, 0) define
an 11-bit mask (bits 10 down to 0)? Would GENMASK(9, 0) be the correct mask
for a 10-bit value to avoid including potentially reserved bits in the ADC
output?

[ ... ]
> @@ -71,13 +96,55 @@ static int loongson2_thermal_set(struct loongson2_thermal_data *data,
>  	return 0;
>  }
>  
> +static int loongson2_2k0300_get_temp(struct thermal_zone_device *tz, int *temp)
> +{
> +	struct loongson2_thermal_data *tdata = thermal_zone_device_priv(tz);
> +	int calib_data, calib_offset, temp_mc, raw_adc;
> +	u32 chip_id0, chip_id1;
> +
> +	writel(0xff03, tdata->ctrl_reg + LOONGSON2_THSENS_CFG_REG);
> +	raw_adc = FIELD_GET(LOONGSON2_THSENS_OUT_10B_MASK,
> +			    readl(tdata->ctrl_reg + LOONGSON2_THSENS_OUT_REG));

[Severity: Medium]
Is a hardware delay or ready-bit poll needed between configuring the ADC and
reading its output register? 

Reading the output immediately after the configuration write might return
incomplete or stale conversion data if the hardware requires time to process
the new configuration.

> +
> +	if (tdata->chip_data->flags & LS2K0300_OLD_FUSE_FLAG) {
> +		*temp = raw_adc * 569 - 394700;
> +		return 0;
> +	}
> +
> +	regmap_read(tdata->regmap_cfg, LS2K0300_CHIP_ID0, &chip_id0);
> +	regmap_read(tdata->regmap_cfg, LS2K0300_CHIP_ID1, &chip_id1);
> +
> +	if (chip_id0 & LS2K0300_EXTERN_ID) {

[Severity: High]
Can these regmap_read() calls fail? If an I/O error or bus failure causes
regmap_read() to return an error code, chip_id0 and chip_id1 would remain
uninitialized.

Using these uninitialized stack values for bitwise mask operations in the
following checks could cause the driver to compute incorrect calibration
offsets and corrupt temperature readings.

> +		calib_data = FIELD_GET(LS2K0300_ID1_VAL_MASK, chip_id1);
> +		calib_offset = FIELD_GET(LS2K0300_COMP_VAL_MASK, calib_data);
> +		if (calib_data & LS2K0300_COMP_SIGN_BIT)
> +			calib_offset = -calib_offset;
> +	} else {
> +		calib_data = FIELD_GET(LS2K0300_ID0_VAL_MASK, chip_id0);
> +		calib_offset = FIELD_GET(LS2K0300_COMP_VAL_MASK, calib_data);
> +	}
> +
> +	tdata->calib_offset = calib_offset;

[Severity: Low]
It looks like tdata->calib_offset is assigned here but never read anywhere
else in the driver.

Since the calibration data is based on fixed hardware fuses, would it be
better to perform this parsing once during driver probe and store the result,
rather than re-reading the syscon registers on every temperature poll?

> +	temp_mc = (raw_adc + calib_offset) * 570 - 394700;
> +
> +	/* For old fuse which can not read right thermal data */
> +	if (temp_mc < LS2K0300_LOWEST_VALID_TEMP || temp_mc > LS2K0300_HIGHEST_VALID_TEMP) {
> +		dev_warn_once(tdata->dev, "It's an old fuse, thermal %d is not right\n", temp_mc);
> +		tdata->chip_data->flags |= LS2K0300_OLD_FUSE_FLAG;

[Severity: High]
Is it safe to modify the flags field of the statically defined shared match
data?

By forcibly casting away the const qualifier from device_get_match_data() in
loongson2_thermal_probe() and then modifying tdata->chip_data->flags here,
the driver alters the global state for all current and future bound instances
of this device.

If one thermal sensor encounters an invalid temperature and sets
LS2K0300_OLD_FUSE_FLAG, this flag will be permanently set for all instances
sharing this match data, incorrectly triggering the fallback formula for
healthy sensors.

> +		temp_mc = raw_adc * 569 - 394700;
> +	}
> +	*temp = temp_mc;
> +
> +	return 0;
> +}

[ ... ]
> @@ -134,7 +205,8 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
>  	if (!data)
>  		return -ENOMEM;
>  
> -	data->chip_data = device_get_match_data(dev);
> +	data->dev = dev;
> +	data->chip_data = (struct loongson2_thermal_chip_data *)device_get_match_data(dev);

[Severity: High]
This cast drops the const qualifier from the match data, which leads to the
global state modification mentioned in loongson2_2k0300_get_temp().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784619512.git.zhoubinbin@loongson.cn?part=4