[PATCH v1 0/3] hwmon: emc1403: Convert to use OF bindings

[PATCH v1 0/3] hwmon: emc1403: Convert to use OF bindings

[Svyatoslav Ryhel]

Document and add OF support to this LM90 compatible thermal sensor
family.

Jonas Schwöbel (1):
  hwmon: (emc1403) Convert to use OF bindings

Svyatoslav Ryhel (2):
  dt-bindings: hwmon: lm90: Document SMSC EMC1402/1403/1404/1428
  hwmon: (emc1403) Add regulator support

 .../bindings/hwmon/national,lm90.yaml         | 109 +++++++++++++-----
 drivers/hwmon/emc1403.c                       |  25 +++-
 2 files changed, 100 insertions(+), 34 deletions(-)

-- 
2.53.0

[PATCH v1 1/3] dt-bindings: hwmon: lm90: Document SMSC EMC1402/1403/1404/1428

[Svyatoslav Ryhel]

Document SMSC (now Microchip) EMC1402/1403/1404/1428 thermal sensors.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 .../bindings/hwmon/national,lm90.yaml         | 109 +++++++++++++-----
 1 file changed, 77 insertions(+), 32 deletions(-)

diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
index 164068ba069d..a1de96e0b87f 100644
--- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
+++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
@@ -12,38 +12,67 @@ maintainers:
 
 properties:
   compatible:
-    enum:
-      - adi,adm1032
-      - adi,adt7461
-      - adi,adt7461a
-      - adi,adt7481
-      - dallas,max6646
-      - dallas,max6647
-      - dallas,max6649
-      - dallas,max6654
-      - dallas,max6657
-      - dallas,max6658
-      - dallas,max6659
-      - dallas,max6680
-      - dallas,max6681
-      - dallas,max6695
-      - dallas,max6696
-      - gmt,g781
-      - national,lm86
-      - national,lm89
-      - national,lm90
-      - national,lm99
-      - nuvoton,nct7716
-      - nuvoton,nct7717
-      - nuvoton,nct7718
-      - nxp,sa56004
-      - onnn,nct72
-      - onnn,nct214
-      - onnn,nct218
-      - onnn,nct1008
-      - ti,tmp451
-      - ti,tmp461
-      - winbond,w83l771
+    oneOf:
+      - enum:
+          - adi,adm1032
+          - adi,adt7461
+          - adi,adt7461a
+          - adi,adt7481
+          - dallas,max6646
+          - dallas,max6647
+          - dallas,max6649
+          - dallas,max6654
+          - dallas,max6657
+          - dallas,max6658
+          - dallas,max6659
+          - dallas,max6680
+          - dallas,max6681
+          - dallas,max6695
+          - dallas,max6696
+          - gmt,g781
+          - national,lm86
+          - national,lm89
+          - national,lm90
+          - national,lm99
+          - nuvoton,nct7716
+          - nuvoton,nct7717
+          - nuvoton,nct7718
+          - nxp,sa56004
+          - onnn,nct72
+          - onnn,nct214
+          - onnn,nct218
+          - onnn,nct1008
+          - smsc,emc1402
+          - smsc,emc1403
+          - smsc,emc1404
+          - smsc,emc1428
+          - ti,tmp451
+          - ti,tmp461
+          - winbond,w83l771
+
+      - items:
+          - enum:
+              - smsc,emc1412
+              - smsc,emc1422
+              - smsc,emc1442
+          - const: smsc,emc1402
+
+      - items:
+          - enum:
+              - smsc,emc1413
+              - smsc,emc1423
+          - const: smsc,emc1403
+
+      - items:
+          - enum:
+              - smsc,emc1414
+              - smsc,emc1424
+          - const: smsc,emc1404
+
+      - items:
+          - enum:
+              - smsc,emc1438
+          - const: smsc,emc1428
 
   interrupts:
     items:
@@ -169,6 +198,7 @@ allOf:
               - national,lm99
               - nuvoton,nct7718
               - nxp,sa56004
+              - smsc,emc1428
               - winbond,w83l771
     then:
       patternProperties:
@@ -191,6 +221,21 @@ allOf:
             temperature-offset-millicelsius:
               maximum: 127937
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - smsc,emc1402
+              - smsc,emc1403
+              - smsc,emc1404
+    then:
+      patternProperties:
+        "^channel@([0-2])$":
+          properties:
+            temperature-offset-millicelsius:
+              maximum: 255875
+
 additionalProperties: false
 
 examples:
-- 
2.53.0

Re: [PATCH v1 1/3] dt-bindings: hwmon: lm90: Document SMSC EMC1402/1403/1404/1428

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The schema artificially restricts the number of allowed channels, rejecting valid hardware configurations for the newly added SMSC EMC1404 and EMC1428 devices.
- [Medium] The dt-binding incorrectly applies maximum temperature threshold limits to the 'temperature-offset-millicelsius' property.
--

commit 7ac2109c4a63c7879d955565cef8a4c30bd05436
Author: Svyatoslav Ryhel <clamor95@gmail.com>

dt-bindings: hwmon: lm90: Document SMSC EMC1402/1403/1404/1428

Document SMSC (now Microchip) EMC1402/1403/1404/1428 thermal sensors.

> diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> index 164068ba069d7..a1de96e0b87f3 100644
> --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
> @@ -12,38 +12,67 @@ maintainers:
>  
>  properties:
>    compatible:
> -    enum:
[ ... ]
> +    oneOf:
> +      - enum:
[ ... ]
> +          - smsc,emc1402
> +          - smsc,emc1403
> +          - smsc,emc1404
> +          - smsc,emc1428

[Severity: Medium]
Does adding smsc,emc1404 and smsc,emc1428 here without expanding the global
channel limits cause schema validation failures for valid hardware?

The emc1403 driver supports up to 4 channels for the EMC1404 and up to 8
channels for the EMC1428. However, the base schema in
Documentation/devicetree/bindings/hwmon/national,lm90.yaml globally restricts
channels:

  patternProperties:
    "^channel@([0-2])$":
      type: object
      ...
      properties:
        reg:
          items:
            minimum: 0
            maximum: 2

With additionalProperties: false at the root, defining channel@3 for EMC1404
or channel@7 for EMC1428 will fail schema validation.

Can we expand the global channel regex and reg bounds, and use if-then blocks
to restrict legacy devices to fewer channels?

[ ... ]
> @@ -169,6 +198,7 @@ allOf:
>                - national,lm99
>                - nuvoton,nct7718
>                - nxp,sa56004
> +              - smsc,emc1428

[Severity: Medium]
Are we confusing the maximum temperature threshold limits with the maximum
offset limit here?

By adding smsc,emc1428 to this block, it inherits a maximum value of 127875
for temperature-offset-millicelsius. In the emc1403.c driver's
emc1403_set_temp() function, temperature thresholds are clamped using
val = clamp_val(val, -128000, 127875) for the emc1428. However, these are
bounds for thresholds (tempX_max, tempX_min, tempX_crit), not temperature
offsets.

The emc1403 driver doesn't seem to support an offset register. Should these
compatibles be added to the block that explicitly sets
temperature-offset-millicelsius: false instead?

>                - winbond,w83l771
>      then:
>        patternProperties:
[ ... ]
> @@ -191,6 +221,21 @@ allOf:
>              temperature-offset-millicelsius:
>                maximum: 127937
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - smsc,emc1402
> +              - smsc,emc1403
> +              - smsc,emc1404
> +    then:
> +      patternProperties:
> +        "^channel@([0-2])$":
> +          properties:
> +            temperature-offset-millicelsius:
> +              maximum: 255875

[Severity: Medium]
Does this block also incorrectly apply temperature threshold maximums to the
offset property?

In the emc1403.c driver's emc1403_set_temp() function, temperature thresholds
for these devices are clamped using val = clamp_val(val, 0, 255875). This
limit applies to threshold registers rather than the offset register.

If the hardware lacks offset support, should
temperature-offset-millicelsius be disabled for these compatibles as well?

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

[PATCH v1 2/3] hwmon: (emc1403) Convert to use OF bindings

[Svyatoslav Ryhel]

From: Jonas Schwöbel <jonasschwoebel@yahoo.de>

Add OF match compatible table to be able to use this driver with Device
Trees.

Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 drivers/hwmon/emc1403.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/emc1403.c b/drivers/hwmon/emc1403.c
index 964a8cb278f1..ac84200be71a 100644
--- a/drivers/hwmon/emc1403.c
+++ b/drivers/hwmon/emc1403.c
@@ -16,6 +16,7 @@
 #include <linux/hwmon.h>
 #include <linux/hwmon-sysfs.h>
 #include <linux/err.h>
+#include <linux/mod_devicetable.h>
 #include <linux/sysfs.h>
 #include <linux/regmap.h>
 #include <linux/util_macros.h>
@@ -659,14 +660,16 @@ static int emc1403_probe(struct i2c_client *client)
 {
 	struct thermal_data *data;
 	struct device *hwmon_dev;
-	const struct i2c_device_id *id = i2c_match_id(emc1403_idtable, client);
 
 	data = devm_kzalloc(&client->dev, sizeof(struct thermal_data),
 			    GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
 
-	data->chip = id->driver_data;
+	data->chip = (enum emc1403_chip)i2c_get_match_data(client);
+	if (!data->chip)
+		return dev_err_probe(&client->dev, -ENODEV, "Unknown device!\n");
+
 	data->regmap = devm_regmap_init_i2c(client, &emc1403_regmap_config);
 	if (IS_ERR(data->regmap))
 		return PTR_ERR(data->regmap);
@@ -682,10 +685,21 @@ static const unsigned short emc1403_address_list[] = {
 	0x18, 0x1c, 0x29, 0x3c, 0x4c, 0x4d, 0x5c, I2C_CLIENT_END
 };
 
+static const struct of_device_id emc1403_of_match[] = {
+	{ .compatible = "smsc,emc1402", .data = (void *)emc1402 },
+	{ .compatible = "smsc,emc1403", .data = (void *)emc1403 },
+	{ .compatible = "smsc,emc1404", .data = (void *)emc1404 },
+	{ .compatible = "smsc,emc1428", .data = (void *)emc1428 },
+	{ }
+
+};
+MODULE_DEVICE_TABLE(of, emc1403_of_match);
+
 static struct i2c_driver sensor_emc1403 = {
 	.class = I2C_CLASS_HWMON,
 	.driver = {
 		.name = "emc1403",
+		.of_match_table = emc1403_of_match,
 	},
 	.detect = emc1403_detect,
 	.probe = emc1403_probe,
-- 
2.53.0

Re: [PATCH v1 2/3] hwmon: (emc1403) Convert to use OF bindings

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The driver probe unconditionally fails for `emc1402` devices because its chip enum value evaluates to 0, which triggers an erroneous error path.
- [Low] Directly casting `const void *` to `enum emc1403_chip` causes a `-Wpointer-to-int-cast` compiler warning on 64-bit architectures.
--

commit 8e14b2d237bb423a526fb43282f03dadf7dbb7dc
Author: Jonas Schwöbel <jonasschwoebel@yahoo.de>

hwmon: (emc1403) Convert to use OF bindings

This commit adds an OF match compatible table. This allows the driver to be 
used with Device Trees.

> diff --git a/drivers/hwmon/emc1403.c b/drivers/hwmon/emc1403.c
> --- a/drivers/hwmon/emc1403.c
> +++ b/drivers/hwmon/emc1403.c
[ ... ]
> @@ -659,14 +660,16 @@ static int emc1403_probe(struct i2c_client *client)
[ ... ]
> -	data->chip = id->driver_data;
> +	data->chip = (enum emc1403_chip)i2c_get_match_data(client);

[Severity: Low]
Does directly casting the pointer returned by i2c_get_match_data() to a 
32-bit enum cause a pointer-to-int-cast compiler warning on 64-bit 
architectures? Would it be safer to cast it to an intermediate 
pointer-sized integer first?

> +	if (!data->chip)

[Severity: High]
Since enum emc1403_chip defines emc1402 as 0, will this check evaluate 
to true for devices compatible with emc1402? It appears this might cause 
the probe function to erroneously return -ENODEV and break initialization 
for chips mapping to emc1402.

> +		return dev_err_probe(&client->dev, -ENODEV, "Unknown device!\n");
> +
>  	data->regmap = devm_regmap_init_i2c(client, &emc1403_regmap_config);
[ ... ]

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

[PATCH v1 3/3] hwmon: (emc1403) Add regulator support

[Svyatoslav Ryhel]

Add support for VCC power supply for this sensor. It is required on some
devices for the sensor to start up and work properly.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 drivers/hwmon/emc1403.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hwmon/emc1403.c b/drivers/hwmon/emc1403.c
index ac84200be71a..dfdd3982efb7 100644
--- a/drivers/hwmon/emc1403.c
+++ b/drivers/hwmon/emc1403.c
@@ -19,6 +19,7 @@
 #include <linux/mod_devicetable.h>
 #include <linux/sysfs.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 #include <linux/util_macros.h>
 
 #define THERMAL_PID_REG		0xfd
@@ -660,6 +661,12 @@ static int emc1403_probe(struct i2c_client *client)
 {
 	struct thermal_data *data;
 	struct device *hwmon_dev;
+	int ret;
+
+	ret = devm_regulator_get_enable(&client->dev, "vcc");
+	if (ret)
+		return dev_err_probe(&client->dev, ret,
+				     "Failed to enable regulator\n");
 
 	data = devm_kzalloc(&client->dev, sizeof(struct thermal_data),
 			    GFP_KERNEL);
-- 
2.53.0

Re: [PATCH v1 3/3] hwmon: (emc1403) Add regulator support

[sashiko-bot]

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

Pre-existing issues:
- [High] The driver fails to probe for `emc1402` and related variants because its enum value is 0, causing it to be mistaken for missing match data.
--

commit 68609b63ba3fac21c7beeccd770258031aea8a06
Author: Svyatoslav Ryhel <clamor95@gmail.com>

hwmon: (emc1403) Add regulator support

This commit adds support for the VCC power supply regulator to the emc1403
sensor driver. It enables the regulator during device probe to ensure the
sensor starts up and functions correctly.

> diff --git a/drivers/hwmon/emc1403.c b/drivers/hwmon/emc1403.c
> index ac84200be71aa..dfdd3982efb7f 100644
> --- a/drivers/hwmon/emc1403.c
> +++ b/drivers/hwmon/emc1403.c
[ ... ]
> @@ -660,6 +661,12 @@ static int emc1403_probe(struct i2c_client *client)
>  {
>  	struct thermal_data *data;
>  	struct device *hwmon_dev;
> +	int ret;
> +
> +	ret = devm_regulator_get_enable(&client->dev, "vcc");
> +	if (ret)
> +		return dev_err_probe(&client->dev, ret,
> +				     "Failed to enable regulator\n");
>  
>  	data = devm_kzalloc(&client->dev, sizeof(struct thermal_data),
>  			    GFP_KERNEL);

[Severity: High]
This is a pre-existing issue, but does this probe function incorrectly fail
for the emc1402 chip variant?

In drivers/hwmon/emc1403.c, the emc1403_chip enum defines emc1402 as the
first element, giving it a value of 0:

enum emc1403_chip { emc1402, emc1403, emc1404, emc1428 };

When emc1403_probe() executes later in this function, i2c_get_match_data()
returns 0 for the emc1402 chip. The subsequent check:

    data->chip = (enum emc1403_chip)i2c_get_match_data(client);
    if (!data->chip)
        return dev_err_probe(&client->dev, -ENODEV, "Unknown device!\n");

will evaluate to true since data->chip is 0, causing the probe to abort
with -ENODEV. Will this inadvertently break support for the emc1402 sensor
family?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603141033.111300-1-clamor95@gmail.com?part=3