[PATCH v4 0/3] hwmon: emc1403: Convert to use OF bindings and add regulator support

[PATCH v4 0/3] hwmon: emc1403: Convert to use OF bindings and add regulator support

[Svyatoslav Ryhel]

Document, add OF and regulator support to EMC14XX thermal sensor family.

Schema file was separated from LM90 since according to Guenter Roeck[1]
these sensors are incompatible with LM90. Proposed schema has basic
hardware description. All registers Guenter Roeck mentioned may be added
later on, when/if driver would need to work with them. As for now driver
successfully works as is.

[1] https://lore.kernel.org/lkml/a0c5c1e8-9a36-4835-a5d9-7bafda79c36f@roeck-us.net/

---
Changes in v2:
- schema separated into a dedicated file
- dropped chip id check
- fixed match data casting
- adjusted regulator name

Changes in v3:
- fixed number on channels for sensors in schema

Changes in v4:
- removed redundant line
---

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

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

 .../bindings/hwmon/smsc,emc1403.yaml          | 203 ++++++++++++++++++
 drivers/hwmon/emc1403.c                       |  21 +-
 2 files changed, 222 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml

-- 
2.53.0

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

[Svyatoslav Ryhel]

Document the basic hardware layout of SMSC (now Microchip)
EMC1402/1403/1404/1428 thermal sensors.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 .../bindings/hwmon/smsc,emc1403.yaml          | 203 ++++++++++++++++++
 1 file changed, 203 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml b/Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml
new file mode 100644
index 0000000000000..d7873a37c3295
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml
@@ -0,0 +1,203 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/smsc,emc1403.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMSC EMC1402/1403/1404/1428 thermal sensors
+
+maintainers:
+  - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+  compatible:
+    oneOf:
+      - enum:
+          - smsc,emc1402
+          - smsc,emc1403
+          - smsc,emc1404
+          - smsc,emc1428
+
+      - 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:
+      - description: Sensors "ALERT" pin output.
+
+  reg:
+    maxItems: 1
+
+  "#thermal-sensor-cells":
+    const: 1
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  vdd-supply: true
+
+required:
+  - compatible
+  - reg
+
+patternProperties:
+  "^channel@([0-7])$":
+    type: object
+    description: Represents channels of the device and their specific configuration.
+
+    properties:
+      reg:
+        description: The channel number. 0 is local channel, 1-7 are remote channels.
+        items:
+          minimum: 0
+          maximum: 7
+
+      label:
+        description: A descriptive name for this channel, like "ambient" or "psu".
+
+    required:
+      - reg
+
+    additionalProperties: false
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - smsc,emc1402
+    then:
+      patternProperties:
+        "^channel@([0-7])$":
+          properties:
+            reg:
+              items:
+                maximum: 1
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - smsc,emc1403
+    then:
+      patternProperties:
+        "^channel@([0-7])$":
+          properties:
+            reg:
+              items:
+                maximum: 2
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - smsc,emc1404
+    then:
+      patternProperties:
+        "^channel@([0-7])$":
+          properties:
+            reg:
+              items:
+                maximum: 3
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sensor@4c {
+            compatible = "smsc,emc1412", "smsc,emc1402";
+            reg = <0x4c>;
+
+            interrupt-parent = <&gpio>;
+            interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+
+            vdd-supply = <&vdd_3v3_sys>;
+            #thermal-sensor-cells = <1>;
+        };
+    };
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sensor@29 {
+            compatible = "smsc,emc1428";
+            reg = <0x29>;
+
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            channel@0 {
+                reg = <0x0>;
+                label = "local";
+            };
+
+            channel@1 {
+                reg = <0x1>;
+                label = "chan1";
+            };
+
+            channel@2 {
+                reg = <0x2>;
+                label = "chan2";
+            };
+
+            channel@3 {
+                reg = <0x3>;
+                label = "chan3";
+            };
+
+            channel@4 {
+                reg = <0x4>;
+                label = "chan4";
+            };
+
+            channel@5 {
+                reg = <0x5>;
+                label = "chan5";
+            };
+
+            channel@6 {
+                reg = <0x6>;
+                label = "chan6";
+            };
+
+            channel@7 {
+                reg = <0x7>;
+                label = "chan7";
+            };
+        };
+    };
-- 
2.53.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Schema Constraint Bypass via incorrect `items` nesting for `reg` property bounds
--

--- Patch [1]: [PATCH v4 1/3] dt-bindings: hwmon: Document SMSC EMC1402/1403/1404/1428 ---
commit 370ec6fbb759eebe7152f9544892c617f0745163
Author: Svyatoslav Ryhel <clamor95@gmail.com>

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

This commit documents the basic hardware layout of SMSC (now Microchip)
EMC1402/1403/1404/1428 thermal sensors and introduces a new YAML device tree
binding schema.

> diff --git a/Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml b/Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml
> new file mode 100644
> index 0000000000000..d7873a37c3295
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/smsc,emc1403.yaml
> @@ -0,0 +1,203 @@

[ ... ]

> +patternProperties:
> +  "^channel@([0-7])$":
> +    type: object
> +    description: Represents channels of the device and their specific configuration.
> +
> +    properties:
> +      reg:
> +        description: The channel number. 0 is local channel, 1-7 are remote channels.
> +        items:
> +          minimum: 0
> +          maximum: 7

[Severity: Medium]
Does nesting the minimum/maximum bounds inside items for the reg property bypass
dt-schema validation?

Since dt-schema decodes reg into an array of regions, numeric bounds placed
under items like this apply to the array element itself and are ignored.
Could these bounds be specified differently so they are correctly enforced
during make dtbs_check?

[ ... ]

> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - smsc,emc1402
> +    then:
> +      patternProperties:
> +        "^channel@([0-7])$":
> +          properties:
> +            reg:
> +              items:
> +                maximum: 1

[Severity: Medium]
Will this stricter bound also be ignored during schema validation due to the
items nesting? 

This could allow an invalid device tree, such as one defining channel@5 for
smsc,emc1402, to silently pass validation checks.

[ ... ]

> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - smsc,emc1403
> +    then:
> +      patternProperties:
> +        "^channel@([0-7])$":
> +          properties:
> +            reg:
> +              items:
> +                maximum: 2

[Severity: Medium]
Does this maximum bound for smsc,emc1403 suffer from the same nesting issue?

[ ... ]

> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - smsc,emc1404
> +    then:
> +      patternProperties:
> +        "^channel@([0-7])$":
> +          properties:
> +            reg:
> +              items:
> +                maximum: 3

[Severity: Medium]
Does the maximum bound for smsc,emc1404 also need to be adjusted to avoid
being ignored by dt-schema?

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

[PATCH v4 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>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 drivers/hwmon/emc1403.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/emc1403.c b/drivers/hwmon/emc1403.c
index cd753b38709f2..8b3173da25973 100644
--- a/drivers/hwmon/emc1403.c
+++ b/drivers/hwmon/emc1403.c
@@ -659,14 +659,14 @@ 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 = (uintptr_t)i2c_get_match_data(client);
+
 	data->regmap = devm_regmap_init_i2c(client, &emc1403_regmap_config);
 	if (IS_ERR(data->regmap))
 		return PTR_ERR(data->regmap);
@@ -682,10 +682,20 @@ 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 v4 2/3] hwmon: (emc1403) Convert to use OF bindings

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The OF match data for 'smsc,emc1402' is set to the enum value `emc1402` (0). This results in a NULL pointer, causing `device_get_match_data()` to incorrectly assume the match data is missing, which triggers an unintended fallback to `id_table` matching.
--

--- Patch [2]: [PATCH v4 2/3] hwmon: (emc1403) Convert to use OF bindings ---
Note: The standard inline diff format for this report has been altered to a
free-form summary due to automated recitation restrictions.

commit 6847b2cd06e049585ee05391183122e70ebf54a0
Author: Jonas Schwöbel <jonasschwoebel@yahoo.de>

hwmon: (emc1403) Convert to use OF bindings

This commit adds an OF match table to the emc1403 driver to enable its
use with Device Trees.

[Severity: Low]
Looking at emc1403_of_match in drivers/hwmon/emc1403.c, the .data field for
"smsc,emc1402" is cast from the enum emc1402. Since emc1402 evaluates to 0,
does this store a NULL pointer in the match data?

When emc1403_probe() calls i2c_get_match_data(client) at line 668,
device_get_match_data() will encounter this NULL pointer and assume the
match data is missing.

Will this cause the I2C subsystem to unintentionally bypass the OF match
data and fall back to string matching against the id_table?

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

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

[Svyatoslav Ryhel]

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

Reviewed-by: Guenter Roeck <linux@roeck-us.net>
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 8b3173da25973..a0f8d29eb6c76 100644
--- a/drivers/hwmon/emc1403.c
+++ b/drivers/hwmon/emc1403.c
@@ -18,6 +18,7 @@
 #include <linux/err.h>
 #include <linux/sysfs.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 #include <linux/util_macros.h>
 
 #define THERMAL_PID_REG		0xfd
@@ -659,6 +660,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, "vdd");
+	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 v4 3/3] hwmon: (emc1403) Add regulator support

[sashiko-bot]

> Add support for VDD power supply for this sensor. It is required on some
> devices for the sensor to start up and work properly.
> 
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

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