[PATCH v2 0/2] hwmon: lm90: Fix DT channel constraints and reject unsupported channel 2

[PATCH v2 0/2] hwmon: lm90: Fix DT channel constraints and reject unsupported channel 2

[Flaviu Nistor]

The intention of this patch series is to fix DT channel constrains in the
dt-bindings and inprove the driver to reject unsupported channel 2.

dt-bindings:
Forbid temperature-offset-millicelsius on channel@0 (local sensor).
Rejecting of assigning temperature-offset-millicelsius for channel@0 is
already implemented in the driver.
Reject channel@2 for compatibles that have only one remote sensor.

driver:
If the sensor have only one remote channel, reject a possible unsupported
channel 2 and return an error, similar to miss-assigment of temperature
-offset-millicelsius property to channel@0.

Flaviu Nistor (2):
  dt-bindings: hwmon: national,lm90: Fix channel constraints for
    temperature offset
  hwmon: (lm90) Reject channel 2 on chips with only one remote sensor

 .../bindings/hwmon/national,lm90.yaml         | 28 +++++++++++++++++--
 drivers/hwmon/lm90.c                          |  5 ++++
 2 files changed, 30 insertions(+), 3 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] dt-bindings: hwmon: national,lm90: Fix channel constraints for temperature offset

[Flaviu Nistor]

Limit temperature-offset-millicelsius to remote channels only, since
channel 0 is local and this property does not apply to it.
Channel 2 is only valid on devices with two remote sensors, so reject
channel 2 for compatibles that do not support a second remote channel.

Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
Changes in v2:
- Use else statement in if/then block as suggested by Conor Dooley. 
- Link to v1: https://lore.kernel.org/all/20260824183900.8983-2-flaviu.nistor@gmail.com/

 .../bindings/hwmon/national,lm90.yaml         | 28 +++++++++++++++++--
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
index 164068ba069d..a8b2a24501b3 100644
--- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
+++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
@@ -113,6 +113,23 @@ allOf:
       properties:
         ti,extended-range-enable: false
 
+  - if:
+      not:
+        properties:
+          compatible:
+            contains:
+              enum:
+                - adi,adt7481
+                - dallas,max6695
+                - dallas,max6696
+    then:
+      patternProperties:
+        "^channel@[0-1]$":
+          properties:
+            reg:
+              enum: [0, 1]
+        "channel@2": false
+
   - if:
       properties:
         compatible:
@@ -134,6 +151,11 @@ allOf:
         "^channel@([0-2])$":
           properties:
             temperature-offset-millicelsius: false
+    else:
+      patternProperties:
+        "channel@0":
+          properties:
+            temperature-offset-millicelsius: false
 
   - if:
       properties:
@@ -149,7 +171,7 @@ allOf:
               - onnn,nct1008
     then:
       patternProperties:
-        "^channel@([0-2])$":
+        "^channel@([1-2])$":
           properties:
             temperature-offset-millicelsius:
               maximum: 127750
@@ -172,7 +194,7 @@ allOf:
               - winbond,w83l771
     then:
       patternProperties:
-        "^channel@([0-2])$":
+        "^channel@([1-2])$":
           properties:
             temperature-offset-millicelsius:
               maximum: 127875
@@ -186,7 +208,7 @@ allOf:
               - ti,tmp461
     then:
       patternProperties:
-        "^channel@([0-2])$":
+        "^channel@([1-2])$":
           properties:
             temperature-offset-millicelsius:
               maximum: 127937
-- 
2.34.1

Re: [PATCH v2 1/2] dt-bindings: hwmon: national,lm90: Fix channel constraints for temperature offset

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Applying `enum: [0, 1]` directly to the `reg` property breaks dtbs validation because `reg` evaluates as an array.
--

commit 962bb439f62765fdf82aa8ab6bf085e5158b3bb7
Author: Flaviu Nistor <flaviu.nistor@gmail.com>

dt-bindings: hwmon: national,lm90: Fix channel constraints for temperature offset

This commit restricts temperature-offset-millicelsius to remote channels and
rejects channel 2 for chips with only one remote sensor. It adds conditional
schema rules to limit the allowed channels based on the compatible string.

> diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> index 164068ba069d7..a8b2a24501b35 100644
> --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> @@ -113,6 +113,23 @@ allOf:
>        properties:
>          ti,extended-range-enable: false
>  
> +  - if:
> +      not:
> +        properties:
> +          compatible:
> +            contains:
> +              enum:
> +                - adi,adt7481
> +                - dallas,max6695
> +                - dallas,max6696
> +    then:
> +      patternProperties:
> +        "^channel@[0-1]$":
> +          properties:
> +            reg:
> +              enum: [0, 1]

[Severity: Low]
Does this schema constraint fail validation?

The dt-schema tooling treats reg as an array based on the core schemas. Since
this block applies enum: [0, 1] directly to reg, an array value like [0] or [1]
will not match the scalar integers 0 or 1 provided in the enum constraint. As a
result, valid device tree nodes containing channel@0 or channel@1 could fail
make dtbs_check with a type mismatch error.

Should this be constrained inside an items block instead, such as
items: enum: [0, 1]?

> +        "channel@2": false

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826184750.4798-1-flaviu.nistor@gmail.com?part=1

Re: [PATCH v2 1/2] dt-bindings: hwmon: national,lm90: Fix channel constraints for temperature offset

[Conor Dooley]

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

On Wed, Aug 26, 2026 at 09:47:48PM +0300, Flaviu Nistor wrote:
> Limit temperature-offset-millicelsius to remote channels only, since
> channel 0 is local and this property does not apply to it.
> Channel 2 is only valid on devices with two remote sensors, so reject
> channel 2 for compatibles that do not support a second remote channel.
> 
> Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
> ---
> Changes in v2:
> - Use else statement in if/then block as suggested by Conor Dooley. 
> - Link to v1: https://lore.kernel.org/all/20260824183900.8983-2-flaviu.nistor@gmail.com/
> 
>  .../bindings/hwmon/national,lm90.yaml         | 28 +++++++++++++++++--
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> index 164068ba069d..a8b2a24501b3 100644
> --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> @@ -113,6 +113,23 @@ allOf:
>        properties:
>          ti,extended-range-enable: false
>  
> +  - if:
> +      not:
> +        properties:
> +          compatible:
> +            contains:
> +              enum:
> +                - adi,adt7481
> +                - dallas,max6695
> +                - dallas,max6696
> +    then:

> +      patternProperties:
> +        "^channel@[0-1]$":
> +          properties:
> +            reg:
> +              enum: [0, 1]

Is this needed? If channel@2 is false, then you won't be able to get to
this point to begin with, right?

Conor.

> +        "channel@2": false
> +
>    - if:
>        properties:
>          compatible:
> @@ -134,6 +151,11 @@ allOf:
>          "^channel@([0-2])$":
>            properties:
>              temperature-offset-millicelsius: false
> +    else:
> +      patternProperties:
> +        "channel@0":
> +          properties:
> +            temperature-offset-millicelsius: false
>  
>    - if:
>        properties:
> @@ -149,7 +171,7 @@ allOf:
>                - onnn,nct1008
>      then:
>        patternProperties:
> -        "^channel@([0-2])$":
> +        "^channel@([1-2])$":
>            properties:
>              temperature-offset-millicelsius:
>                maximum: 127750
> @@ -172,7 +194,7 @@ allOf:
>                - winbond,w83l771
>      then:
>        patternProperties:
> -        "^channel@([0-2])$":
> +        "^channel@([1-2])$":
>            properties:
>              temperature-offset-millicelsius:
>                maximum: 127875
> @@ -186,7 +208,7 @@ allOf:
>                - ti,tmp461
>      then:
>        patternProperties:
> -        "^channel@([0-2])$":
> +        "^channel@([1-2])$":
>            properties:
>              temperature-offset-millicelsius:
>                maximum: 127937
> -- 
> 2.34.1
> 

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

Re: [PATCH v2 1/2] dt-bindings: hwmon: national,lm90: Fix channel constraints for temperature offset

[Conor Dooley]

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

On Thu, Aug 27, 2026 at 06:01:28PM +0100, Conor Dooley wrote:
> On Wed, Aug 26, 2026 at 09:47:48PM +0300, Flaviu Nistor wrote:
> > Limit temperature-offset-millicelsius to remote channels only, since
> > channel 0 is local and this property does not apply to it.
> > Channel 2 is only valid on devices with two remote sensors, so reject
> > channel 2 for compatibles that do not support a second remote channel.
> > 
> > Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
> > ---
> > Changes in v2:
> > - Use else statement in if/then block as suggested by Conor Dooley. 
> > - Link to v1: https://lore.kernel.org/all/20260824183900.8983-2-flaviu.nistor@gmail.com/
> > 
> >  .../bindings/hwmon/national,lm90.yaml         | 28 +++++++++++++++++--
> >  1 file changed, 25 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> > index 164068ba069d..a8b2a24501b3 100644
> > --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> > +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> > @@ -113,6 +113,23 @@ allOf:
> >        properties:
> >          ti,extended-range-enable: false
> >  
> > +  - if:
> > +      not:
> > +        properties:
> > +          compatible:
> > +            contains:
> > +              enum:
> > +                - adi,adt7481
> > +                - dallas,max6695
> > +                - dallas,max6696
> > +    then:
> 
> > +      patternProperties:
> > +        "^channel@[0-1]$":
> > +          properties:
> > +            reg:
> > +              enum: [0, 1]
> 
> Is this needed? If channel@2 is false, then you won't be able to get to
> this point to begin with, right?

Hmm, actually keep it. It'd fail dtbs_check but I don't think
dt_binding_check fails for channel@0 + reg = <2>

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

> 
> Conor.
> 
> > +        "channel@2": false
> > +
> >    - if:
> >        properties:
> >          compatible:
> > @@ -134,6 +151,11 @@ allOf:
> >          "^channel@([0-2])$":
> >            properties:
> >              temperature-offset-millicelsius: false
> > +    else:
> > +      patternProperties:
> > +        "channel@0":
> > +          properties:
> > +            temperature-offset-millicelsius: false
> >  
> >    - if:
> >        properties:
> > @@ -149,7 +171,7 @@ allOf:
> >                - onnn,nct1008
> >      then:
> >        patternProperties:
> > -        "^channel@([0-2])$":
> > +        "^channel@([1-2])$":
> >            properties:
> >              temperature-offset-millicelsius:
> >                maximum: 127750
> > @@ -172,7 +194,7 @@ allOf:
> >                - winbond,w83l771
> >      then:
> >        patternProperties:
> > -        "^channel@([0-2])$":
> > +        "^channel@([1-2])$":
> >            properties:
> >              temperature-offset-millicelsius:
> >                maximum: 127875
> > @@ -186,7 +208,7 @@ allOf:
> >                - ti,tmp461
> >      then:
> >        patternProperties:
> > -        "^channel@([0-2])$":
> > +        "^channel@([1-2])$":
> >            properties:
> >              temperature-offset-millicelsius:
> >                maximum: 127937
> > -- 
> > 2.34.1
> > 



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

[PATCH v2 2/2] hwmon: (lm90) Reject channel 2 on chips with only one remote sensor

[Flaviu Nistor]

Validate firmware channel definitions against chip capabilities and return
-EINVAL when channel 2 is configured on devices with 1 remote channel.

Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
 drivers/hwmon/lm90.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index 1c603272538a..3faeb2c6ab01 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -2712,6 +2712,11 @@ static int lm90_probe_channel(struct i2c_client *client,
 		return -EINVAL;
 	}
 
+	if (id == 2 && !(data->flags & LM90_HAVE_TEMP3)) {
+		dev_err(dev, "channel %d is not supported for this chip in %pfw\n", id, child);
+		return -EINVAL;
+	}
+
 	err = fwnode_property_read_string(child, "label", &data->channel_label[id]);
 	if (err == -ENODATA || err == -EILSEQ) {
 		dev_err(dev, "invalid label property in %pfw\n", child);
-- 
2.34.1

Re: [PATCH v2 2/2] hwmon: (lm90) Reject channel 2 on chips with only one remote sensor

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Incorrect format specifier '%d' used for 'u32' variable.
--

commit dbab4ee8e2d548c97ffd31b1a3d640af352905b1
Author: Flaviu Nistor <flaviu.nistor@gmail.com>

hwmon: (lm90) Reject channel 2 on chips with only one remote sensor

This commit validates firmware channel definitions against chip capabilities
and returns -EINVAL when channel 2 is configured on devices with 1 remote
channel.

> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
> index 1c603272538aa..3faeb2c6ab01b 100644
> --- a/drivers/hwmon/lm90.c
> +++ b/drivers/hwmon/lm90.c
> @@ -2712,6 +2712,11 @@ static int lm90_probe_channel(struct i2c_client *client,
>  		return -EINVAL;
>  	}
>  
> +	if (id == 2 && !(data->flags & LM90_HAVE_TEMP3)) {
> +		dev_err(dev, "channel %d is not supported for this chip in %pfw\n", id, child);

[Severity: Low]
Does this code use the correct format specifier for the id variable?

While passing an unsigned 32-bit integer to a %d specifier works for small
values (since id is guaranteed to be exactly 2 on this path), it is
semantically incorrect for a u32 variable and violates format string
contracts, leading to potential compiler warnings (-Wformat).

Would it be better to use %u as the format specifier for a u32?

> +		return -EINVAL;
> +	}
> +
>  	err = fwnode_property_read_string(child, "label", &data->channel_label[id]);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826184750.4798-1-flaviu.nistor@gmail.com?part=2