[PATCH v2 0/2] thermal: imx: Add calibration offset support

[PATCH v2 0/2] thermal: imx: Add calibration offset support

[HaoNing Cheng via B4 Relay]

Some i.MX boards need a small per-design correction to align the
reported CPU temperature with board-level measurements. This series
adds an optional DT property to specify such a calibration offset
and implements the corresponding support in the imx_thermal driver.

Patch 1 documents the new fsl,temp-calibration-offset-millicelsius
property in the i.MX thermal DT binding.

Patch 2 reads this property in the imx_thermal driver and applies
the offset to the i.MX6/6SX/7D calibration formulas. When the
property is absent, the default offset remains 0, preserving the
current behaviour.

Signed-off-by: Haoning CHENG <Haoning.CHENG@cn.bosch.com>
---
Changes in v2:
- dt-bindings: Removed explicit `$ref: /schemas/types.yaml#/definitions/int32`
  for fsl,temp-calibration-offset-millicelsius; the `-millicelsius` suffix
  already resolves to int32-array via property-units.yaml (Rob).
- dt-bindings: Fixed example indentation.
- driver: Replaced C integer division (/) with DIV_ROUND_CLOSEST() in
  imx_set_alarm_temp() to prevent off-by-one alarm threshold mismatch that
  could cause IRQ storms on i.MX7D.
- driver: Added clamp() bounds check for alarm_value [0, 0x1ff] to avoid
  corrupting adjacent register fields (PANIC_ALARM).
- Link to v1: https://patch.msgid.link/20260709-b4-symana21-11221-imx-thermal-support-upstream-6-18-v1-0-00f88f42930b@cn.bosch.com

To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Lukasz Luba <lukasz.luba@arm.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Shawn Guo <shawnguo@kernel.org>
To: Sascha Hauer <s.hauer@pengutronix.de>
To: Pengutronix Kernel Team <kernel@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
Cc: linux-pm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org

---
HaoNing Cheng (2):
      dt-bindings: thermal: imx: Document calibration offset property
      thermal/drivers/imx: Add calibration offset support

 .../devicetree/bindings/thermal/imx-thermal.yaml       |  8 ++++++++
 drivers/thermal/imx_thermal.c                          | 18 +++++++++++++-----
 2 files changed, 21 insertions(+), 5 deletions(-)
---
base-commit: c50a940dcde35c647e097e89a9150003abd48329
change-id: 20260709-b4-symana21-11221-imx-thermal-support-upstream-6-18-a084984deb76

Best regards,
--  
Haoning CHENG <Haoning.CHENG@cn.bosch.com>

[PATCH v2 1/2] dt-bindings: thermal: imx: Document calibration offset property

[HaoNing Cheng via B4 Relay]

From: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>

Some boards need a small per-design correction to align the reported CPU
temperature with board-level measurements.

Document the optional fsl,temp-calibration-offset-millicelsius property,
a signed offset in millicelsius that is added to the calculated sensor
temperature. The property is optional and the existing behaviour is kept
when it is omitted.

Update the binding example to show its usage.

Signed-off-by: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>
---
 Documentation/devicetree/bindings/thermal/imx-thermal.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
index 949b154856c5..eb7243a7ebaf 100644
--- a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
@@ -59,6 +59,13 @@ properties:
   clocks:
     maxItems: 1
 
+  fsl,temp-calibration-offset-millicelsius:
+    maxItems: 1
+    description:
+      A signed calibration offset, in millicelsius, added to the calculated
+      sensor temperature to compensate for board-level measurement
+      differences. When absent, no offset is applied.
+
   "#thermal-sensor-cells":
     const: 0
 
@@ -109,6 +116,7 @@ examples:
             nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
             nvmem-cell-names = "calib", "temp_grade";
             clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
+            fsl,temp-calibration-offset-millicelsius = <(-6400)>;
             #thermal-sensor-cells = <0>;
         };
     };

-- 
2.43.0

[PATCH v2 2/2] thermal/drivers/imx: Add calibration offset support

[HaoNing Cheng via B4 Relay]

From: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>

Some boards need a small per-design correction to align the reported CPU
temperature with board-level measurements.

Read the optional fsl,temp-calibration-offset-millicelsius property from
DT and apply it to the i.MX6/6SX/7D calibration formulas. When the
property is not present, the default offset remains 0, preserving the
current behaviour.

Signed-off-by: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>
---
 drivers/thermal/imx_thermal.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 38c993d1bcb3..8062d34ffed8 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -207,6 +207,7 @@ struct imx_thermal_data {
 	struct regmap *tempmon;
 	u32 c1, c2; /* See formula in imx_init_calib() */
 	int temp_max;
+	s32 calibration_offset;
 	int alarm_temp;
 	int last_temp;
 	bool irq_enabled;
@@ -240,10 +241,13 @@ static void imx_set_alarm_temp(struct imx_thermal_data *data,
 
 	data->alarm_temp = alarm_temp;
 
-	if (data->socdata->version == TEMPMON_IMX7D)
-		alarm_value = alarm_temp / 1000 + data->c1 - 25;
-	else
+	if (data->socdata->version == TEMPMON_IMX7D) {
+		alarm_value = DIV_ROUND_UP(alarm_temp - data->calibration_offset,
+					   1000) + data->c1 - 25;
+		alarm_value = clamp(alarm_value, 0, 0x1ff);
+	} else {
 		alarm_value = (data->c2 - alarm_temp) / data->c1;
+	}
 
 	regmap_write(map, soc_data->high_alarm_ctrl + REG_CLR,
 		     soc_data->high_alarm_mask);
@@ -274,7 +278,7 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
 
 	/* See imx_init_calib() for formula derivation */
 	if (data->socdata->version == TEMPMON_IMX7D)
-		*temp = (n_meas - data->c1 + 25) * 1000;
+		*temp = (n_meas - data->c1 + 25) * 1000 + data->calibration_offset;
 	else
 		*temp = data->c2 - n_meas * data->c1;
 
@@ -413,7 +417,7 @@ static int imx_init_calib(struct platform_device *pdev, u32 ocotp_ana1)
 	temp64 *= 1000; /* to get result in °mC */
 	do_div(temp64, 15423 * n1 - 4148468);
 	data->c1 = temp64;
-	data->c2 = n1 * data->c1 + 28581;
+	data->c2 = n1 * data->c1 + 28581 + data->calibration_offset;
 
 	return 0;
 }
@@ -629,6 +633,10 @@ static int imx_thermal_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, data);
 
+	of_property_read_s32(dev->of_node,
+			     "fsl,temp-calibration-offset-millicelsius",
+			     &data->calibration_offset);
+
 	if (of_property_present(dev->of_node, "nvmem-cells")) {
 		ret = imx_init_from_nvmem_cells(pdev);
 		if (ret)

-- 
2.43.0

Re: [PATCH v2 2/2] thermal/drivers/imx: Add calibration offset support

[sashiko-bot]

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

Pre-existing issues:
- [High] Premature thermal zone registration exposes sysfs before the IRQ is requested, allowing unbalanced IRQ enable/disable operations.
- [High] Data race on `data->irq_enabled` between process context and hardirq context leads to unbalanced IRQ disable depths and permanently disabled interrupts.
- [High] Use-After-Free of `data->tz` in the thermal alarm IRQ thread during driver removal due to skipped `disable_irq()` synchronization.
--

--- Patch [2]: [PATCH v2 2/2] thermal/drivers/imx: Add calibration offset support ---
commit 7cfd21023fa90494618a836d7b36a5a78f4f8447
Author: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>

thermal/drivers/imx: Add calibration offset support
    
Some boards need a small per-design correction to align the reported CPU
temperature with board-level measurements.

Read the optional fsl,temp-calibration-offset-millicelsius property from
DT and apply it to the i.MX6/6SX/7D calibration formulas.

> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index 5aaacbc534786..971d6b4737c68 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c

[ ... ]

> @@ -274,7 +278,7 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
>  
>  	/* See imx_init_calib() for formula derivation */
>  	if (data->socdata->version == TEMPMON_IMX7D)
> -		*temp = (n_meas - data->c1 + 25) * 1000;
> +		*temp = (n_meas - data->c1 + 25) * 1000 + data->calibration_offset;
>  	else
>  		*temp = data->c2 - n_meas * data->c1;

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential race
condition involving the sysfs exposure of this temperature read.

In imx_thermal_probe(), the thermal zone is registered before the IRQ is
requested:

imx_thermal_probe() {
    data->tz = thermal_zone_device_register_with_trips(...)
    ...
    ret = devm_request_threaded_irq(...)
}

Could userspace trigger a read through sysfs immediately after registration,
calling into imx_get_temp() before the IRQ is fully requested?

If so, and if it reaches this path:

imx_get_temp() {
    if (!data->irq_enabled && *temp < data->alarm_temp) {
        data->irq_enabled = true;
        enable_irq(data->irq);
    }
}

Would it call enable_irq() on an unrequested IRQ, leading to unbalanced IRQ
enable/disable operations?

Furthermore, if devm_request_threaded_irq() fails, the error path
unregisters the thermal zone, which calls
imx_change_mode(THERMAL_DEVICE_DISABLED).  Since data->irq_enabled was set
to true, would it deterministically call disable_irq() on the unrequested IRQ?

[ ... ]

> @@ -629,6 +633,10 @@ static int imx_thermal_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, data);
>  
> +	of_property_read_s32(dev->of_node,
> +			     "fsl,temp-calibration-offset-millicelsius",
> +			     &data->calibration_offset);
> +

[Severity: High]
This is a pre-existing issue, but while reviewing the IRQ handling in this
driver, I noticed a potential data race on data->irq_enabled between process
context and hardirq context.

The flag is accessed and modified in imx_change_mode() without
synchronization:

imx_change_mode() {
    if (data->irq_enabled) {
        disable_irq(data->irq);
        data->irq_enabled = false;
    }
}

It is also concurrently modified in hardirq context:

imx_thermal_alarm_irq() {
    disable_irq_nosync(data->irq);
    data->irq_enabled = false;
}

If imx_change_mode(THERMAL_DEVICE_DISABLED) reads data->irq_enabled as true,
and an alarm interrupt fires immediately after on another CPU, the hardirq
handler will run, call disable_irq_nosync(), and set the flag to false.

When the hardirq completes, would imx_change_mode() resume and
unconditionally call disable_irq(), incrementing the IRQ disable depth to 2?

Would subsequent reenables only decrement it by 1, leaving the hardware IRQ
permanently disabled?

[Severity: High]
This is another pre-existing issue related to the IRQ handling, but I
noticed a potential use-after-free of data->tz in the thermal alarm IRQ
thread during driver removal.

During imx_thermal_remove(), thermal_zone_device_unregister() is called,
which internally sets the mode to disabled by calling
imx_change_mode(THERMAL_DEVICE_DISABLED).

If a thermal alarm interrupt fired just prior, the hardirq handler will have
set data->irq_enabled = false and woken up the IRQ thread.  Because
data->irq_enabled is now false, imx_change_mode() skips calling disable_irq():

imx_change_mode() {
    if (data->irq_enabled) {
        disable_irq(data->irq);
    }
}

By skipping disable_irq(), does it fail to provide the required
synchronization barrier to wait for the IRQ thread to complete?

If thermal_zone_device_unregister() proceeds to free data->tz, could the
still-running imx_thermal_alarm_irq_thread() then dereference the freed
pointer:

imx_thermal_alarm_irq_thread() {
    thermal_zone_device_update(data->tz, THERMAL_EVENT_UNSPECIFIED);
}

Would this lead to a use-after-free?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-b4-symana21-11221-imx-thermal-support-upstream-6-18-v2-0-00ff72495e24@cn.bosch.com?part=2

Re: [PATCH v2 1/2] dt-bindings: thermal: imx: Document calibration offset property

[Frank Li]

On Thu, Jul 09, 2026 at 04:10:21PM +0800, HaoNing Cheng via B4 Relay wrote:
> [You don't often get email from devnull+haoning.cheng.cn.bosch.com@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>
>
> Some boards need a small per-design correction to align the reported CPU
> temperature with board-level measurements.
>
> Document the optional fsl,temp-calibration-offset-millicelsius property,
> a signed offset in millicelsius that is added to the calculated sensor
> temperature.

why board difference cause such offset, I suppose it is cause by SoC
variance. The offset may difference if you change to another chip. another
words, if you have 1000 boards, Is this offset the same?


> The property is optional and the existing behaviour is kept
> when it is omitted.
>
> Update the binding example to show its usage.
>
> Signed-off-by: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>
> ---
>  Documentation/devicetree/bindings/thermal/imx-thermal.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
> index 949b154856c5..eb7243a7ebaf 100644
> --- a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
> @@ -59,6 +59,13 @@ properties:
>    clocks:
>      maxItems: 1
>
> +  fsl,temp-calibration-offset-millicelsius:
> +    maxItems: 1

suppose it int32, why need maxItems here?

Frank

> +    description:
> +      A signed calibration offset, in millicelsius, added to the calculated
> +      sensor temperature to compensate for board-level measurement
> +      differences. When absent, no offset is applied.
> +
>    "#thermal-sensor-cells":
>      const: 0
>
> @@ -109,6 +116,7 @@ examples:
>              nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
>              nvmem-cell-names = "calib", "temp_grade";
>              clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
> +            fsl,temp-calibration-offset-millicelsius = <(-6400)>;
>              #thermal-sensor-cells = <0>;
>          };
>      };
>
> --
> 2.43.0
>
>
>

Re: [PATCH v2 1/2] dt-bindings: thermal: imx: Document calibration offset property

[Conor Dooley]

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

On Thu, Jul 09, 2026 at 10:07:21AM -0500, Frank Li wrote:
> On Thu, Jul 09, 2026 at 04:10:21PM +0800, HaoNing Cheng via B4 Relay wrote:
> > [You don't often get email from devnull+haoning.cheng.cn.bosch.com@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > From: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>
> >
> > Some boards need a small per-design correction to align the reported CPU
> > temperature with board-level measurements.
> >
> > Document the optional fsl,temp-calibration-offset-millicelsius property,
> > a signed offset in millicelsius that is added to the calculated sensor
> > temperature.
> 
> why board difference cause such offset, I suppose it is cause by SoC
> variance. The offset may difference if you change to another chip. another
> words, if you have 1000 boards, Is this offset the same?

I think your "in other words" section here is confusing.
You're asking about "1000 boards", which would imply that it is 1000 of
the same design of board. The commit message says that the variance is
between designs. If 1000 of the same design of board have the same offset,
but 2 boards with different designs have different ones then this
property seems fair. Of course, if the variance is determined by the SoC
in use, then this should be deduced from the compatible, but the commit
message seems to be fairly clear about it not being SoC related.

> 
> 
> > The property is optional and the existing behaviour is kept
> > when it is omitted.
> >
> > Update the binding example to show its usage.
> >
> > Signed-off-by: HaoNing Cheng <Haoning.CHENG@cn.bosch.com>
> > ---
> >  Documentation/devicetree/bindings/thermal/imx-thermal.yaml | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
> > index 949b154856c5..eb7243a7ebaf 100644
> > --- a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
> > +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
> > @@ -59,6 +59,13 @@ properties:
> >    clocks:
> >      maxItems: 1
> >
> > +  fsl,temp-calibration-offset-millicelsius:
> > +    maxItems: 1
> 
> suppose it int32, why need maxItems here?

  "-millicelsius$":
    $ref: types.yaml#/definitions/int32-array

What's missing are constraints on the max and min I think though.
pw-bot: changes-requested

Thanks,
Conor.

> 
> Frank
> 
> > +    description:
> > +      A signed calibration offset, in millicelsius, added to the calculated
> > +      sensor temperature to compensate for board-level measurement
> > +      differences. When absent, no offset is applied.
> > +
> >    "#thermal-sensor-cells":
> >      const: 0
> >
> > @@ -109,6 +116,7 @@ examples:
> >              nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
> >              nvmem-cell-names = "calib", "temp_grade";
> >              clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
> > +            fsl,temp-calibration-offset-millicelsius = <(-6400)>;
> >              #thermal-sensor-cells = <0>;
> >          };
> >      };
> >
> > --
> > 2.43.0
> >
> >
> >

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