[PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property

[PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property

[Flaviu Nistor]

Add support for an optional label property similar to other hwmon devices.
This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
distinct names to each instance.

Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
 .../devicetree/bindings/hwmon/amphenol,chipcap2.yaml         | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
index 17351fdbefce..f00b5a4b14dd 100644
--- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
+++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
@@ -33,6 +33,10 @@ properties:
   reg:
     maxItems: 1
 
+  label:
+    description:
+      A descriptive name for this channel, like "ambient" or "psu".
+
   interrupts:
     items:
       - description: measurement ready indicator
@@ -72,6 +76,7 @@ examples:
                          <5 IRQ_TYPE_EDGE_RISING>,
                          <6 IRQ_TYPE_EDGE_RISING>;
             interrupt-names = "ready", "low", "high";
+            label = "somelabel";
             vdd-supply = <&reg_vdd>;
         };
     };
-- 
2.34.1

[PATCH 2/2] hwmon: (chipcap2) Add support for label

[Flaviu Nistor]

Add support for label sysfs attribute similar to other hwmon devices.
This is particularly useful for systems with multiple sensors on the
same board, where identifying individual sensors is much easier since
labels can be defined via device tree.

Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
 Documentation/hwmon/chipcap2.rst |  2 ++
 drivers/hwmon/chipcap2.c         | 25 +++++++++++++++++++++++--
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/hwmon/chipcap2.rst b/Documentation/hwmon/chipcap2.rst
index dc165becc64c..c38d87b91b69 100644
--- a/Documentation/hwmon/chipcap2.rst
+++ b/Documentation/hwmon/chipcap2.rst
@@ -70,4 +70,6 @@ humidity1_min_hyst:             RW      humidity low hystersis
 humidity1_max_hyst:             RW      humidity high hystersis
 humidity1_min_alarm:            RO      humidity low alarm indicator
 humidity1_max_alarm:            RO      humidity high alarm indicator
+humidity1_label:                RO      descriptive name for the sensor
+temp1_label:                    RO      descriptive name for the sensor
 =============================== ======= ========================================
diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
index 4aecf463180f..086571d556b7 100644
--- a/drivers/hwmon/chipcap2.c
+++ b/drivers/hwmon/chipcap2.c
@@ -22,6 +22,8 @@
 #include <linux/irq.h>
 #include <linux/module.h>
 #include <linux/regulator/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/property.h>
 
 #define CC2_START_CM			0xA0
 #define CC2_START_NOM			0x80
@@ -83,6 +85,7 @@ struct cc2_data {
 	struct i2c_client *client;
 	struct regulator *regulator;
 	const char *name;
+	const char *label;
 	int irq_ready;
 	int irq_low;
 	int irq_high;
@@ -449,6 +452,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
 		switch (attr) {
 		case hwmon_humidity_input:
 			return 0444;
+		case hwmon_humidity_label:
+			return cc2->label ? 0444 : 0;
 		case hwmon_humidity_min_alarm:
 			return cc2->rh_alarm.low_alarm_visible ? 0444 : 0;
 		case hwmon_humidity_max_alarm:
@@ -466,6 +471,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
 		switch (attr) {
 		case hwmon_temp_input:
 			return 0444;
+		case hwmon_temp_label:
+			return cc2->label ? 0444 : 0;
 		default:
 			return 0;
 		}
@@ -552,6 +559,16 @@ static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
 	return 0;
 }
 
+static int cc2_read_string(struct device *dev, enum hwmon_sensor_types type,
+			   u32 attr, int channel, const char **str)
+{
+	struct cc2_data *data = dev_get_drvdata(dev);
+
+	*str = data->label;
+
+	return 0;
+}
+
 static int cc2_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
 		    int channel, long *val)
 {
@@ -670,8 +687,9 @@ static int cc2_request_alarm_irqs(struct cc2_data *data, struct device *dev)
 }
 
 static const struct hwmon_channel_info *cc2_info[] = {
-	HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
-	HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_MIN | HWMON_H_MAX |
+	HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+	HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_LABEL |
+			   HWMON_H_MIN | HWMON_H_MAX |
 			   HWMON_H_MIN_HYST | HWMON_H_MAX_HYST |
 			   HWMON_H_MIN_ALARM | HWMON_H_MAX_ALARM),
 	NULL
@@ -680,6 +698,7 @@ static const struct hwmon_channel_info *cc2_info[] = {
 static const struct hwmon_ops cc2_hwmon_ops = {
 	.is_visible = cc2_is_visible,
 	.read = cc2_read,
+	.read_string = cc2_read_string,
 	.write = cc2_write,
 };
 
@@ -710,6 +729,8 @@ static int cc2_probe(struct i2c_client *client)
 		return dev_err_probe(dev, PTR_ERR(data->regulator),
 				     "Failed to get regulator\n");
 
+	device_property_read_string(dev, "label", &data->label);
+
 	ret = cc2_request_ready_irq(data, dev);
 	if (ret)
 		return dev_err_probe(dev, ret, "Failed to request ready irq\n");
-- 
2.34.1

Re: [PATCH 2/2] hwmon: (chipcap2) Add support for label

[sashiko-bot]

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

Pre-existing issues:
- [High] Data race on shared state between threaded interrupt handlers and sysfs context, violating hwmon subsystem guidelines.
--

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

hwmon: (chipcap2) Add support for label

This commit adds support for the label sysfs attribute to the chipcap2 hwmon
device. This allows for easier identification of individual sensors via the
device tree.

> diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
> index 4aecf463180fd..086571d556b7e 100644
> --- a/drivers/hwmon/chipcap2.c
> +++ b/drivers/hwmon/chipcap2.c
[ ... ]
> @@ -552,6 +559,16 @@ static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
>  	return 0;
>  }
>  

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this driver I
noticed a potential data race. Does the driver access and modify shared
variables (rh_alarm.low_alarm) concurrently from both sysfs read paths and
threaded interrupt handlers without locking?

In the sysfs process context, the flag is evaluated and cleared without locks:

drivers/hwmon/chipcap2.c:cc2_humidity_min_alarm_status() {
    ...
    if (data->rh_alarm.low_alarm) {
        *val = (measurement < min_hyst) ? 1 : 0;
        data->rh_alarm.low_alarm = *val;
    } else {
        *val = 0;
    }
    ...
}

Concurrently, the threaded interrupt handler sets the flag:

drivers/hwmon/chipcap2.c:cc2_low_interrupt() {
    ...
    if (cc2->process_irqs) {
        hwmon_notify_event(cc2->hwmon, hwmon_humidity,
                           hwmon_humidity_min_alarm, CC2_CHAN_HUMIDITY);
        cc2->rh_alarm.low_alarm = true;
    }
    ...
}

The hwmon subsystem guidelines mandate that drivers must implement locking
required for interrupt handling, specifically recommending the use of
hwmon_lock() and hwmon_unlock() to serialize operations. Can these paths
race and cause state corruption or lost alarm events?

> +static int cc2_read_string(struct device *dev, enum hwmon_sensor_types type,
> +			   u32 attr, int channel, const char **str)
> +{
> +	struct cc2_data *data = dev_get_drvdata(dev);
> +
> +	*str = data->label;
> +
> +	return 0;
> +}
> +

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

Re: [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property

[sashiko-bot]

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

New issues:
- [Low] The 'label' property description incorrectly refers to 'this channel', but the property is applied to the top-level device node.

Pre-existing issues:
- [High] Threaded interrupt handlers modify shared state without holding any locks, violating hwmon subsystem guidelines and causing potential loss of alarm events.
--

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

dt-bindings: hwmon: chipcap2: Add label property

Add support for an optional label property similar to other hwmon devices.
This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
distinct names to each instance.

> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> index 17351fdbefce6..f00b5a4b14ddd 100644
> --- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> @@ -33,6 +33,10 @@ properties:
>    reg:
>      maxItems: 1
>  
> +  label:
> +    description:
> +      A descriptive name for this channel, like "ambient" or "psu".

[Severity: Low]
Is this description accurate? The label property is being added to the
root node, so it applies to the entire device/instance rather than a single
channel.

The chipcap2 sensor provides multiple channels via a single device
node. Could the description be updated to clarify it names the entire sensor
rather than a single channel?

> +
>    interrupts:
>      items:
>        - description: measurement ready indicator

[Severity: High]
This is a pre-existing issue, but does drivers/hwmon/chipcap2.c lack
locking between the threaded interrupt handlers and the sysfs paths, which
could lead to lost alarm events?

The threaded interrupt handlers modify shared state without holding any
locks, which violates hwmon subsystem guidelines.

If an interrupt fires between the sysfs read and write:

CPU1 in drivers/hwmon/chipcap2.c:cc2_humidity_min_alarm_status() {
	...
	if (data->rh_alarm.low_alarm) {
		*val = (measurement < min_hyst) ? 1 : 0;

CPU2 in drivers/hwmon/chipcap2.c:cc2_low_interrupt() {
		cc2->rh_alarm.low_alarm = true;
}

CPU1 continues:
		data->rh_alarm.low_alarm = *val;
	} else {
		*val = 0;
	}
	...
}

The interrupt's update will be overwritten with 0 and permanently lost. The
hwmon subsystem guidelines require drivers to implement locking for interrupt
handling and sysfs attributes, recommending the use of hwmon_lock() and
hwmon_unlock().

Could this concurrent access to data->rh_alarm.low_alarm be protected?

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

Re: [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property

[Javier Carrasco]

On Mon Jun 22, 2026 at 2:21 PM CEST, Flaviu Nistor wrote:
> Add support for an optional label property similar to other hwmon devices.
> This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
> distinct names to each instance.
>
> Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
> ---
>  .../devicetree/bindings/hwmon/amphenol,chipcap2.yaml         | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> index 17351fdbefce..f00b5a4b14dd 100644
> --- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> @@ -33,6 +33,10 @@ properties:
>    reg:
>      maxItems: 1
>
> +  label:
> +    description:
> +      A descriptive name for this channel, like "ambient" or "psu".
> +
>    interrupts:
>      items:
>        - description: measurement ready indicator
> @@ -72,6 +76,7 @@ examples:
>                           <5 IRQ_TYPE_EDGE_RISING>,
>                           <6 IRQ_TYPE_EDGE_RISING>;
>              interrupt-names = "ready", "low", "high";
> +            label = "somelabel";
>              vdd-supply = <&reg_vdd>;
>          };
>      };

Hello Falviu, thank you for your patch.

Should we not add a reference to hwmon-common.yaml (with
unevelautedProperties instead of additionalProperties), as label is
defined there? I believe that Krzysztof Kozlowski did something similar
for the shunt-resistor-micro-ohms property. Could we follow suit here?

I am also not a big fan of a name like "somelabel", and a more
meaningful name from a "real" example would look better. I know that
some examples have already used "somelabel" as an example, but others
have used more meaningful names too.

Best regards,
Javier Carrasco

Re: [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property

[Javier Carrasco]

On Mon Jun 22, 2026 at 2:32 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
...
> Pre-existing issues:
> - [High] Threaded interrupt handlers modify shared state without holding any locks, violating hwmon subsystem guidelines and causing potential loss of alarm events.
> --
> [Severity: High]
> This is a pre-existing issue, but does drivers/hwmon/chipcap2.c lack
> locking between the threaded interrupt handlers and the sysfs paths, which
> could lead to lost alarm events?
>
> The threaded interrupt handlers modify shared state without holding any
> locks, which violates hwmon subsystem guidelines.
>
> If an interrupt fires between the sysfs read and write:
>
> CPU1 in drivers/hwmon/chipcap2.c:cc2_humidity_min_alarm_status() {
> 	...
> 	if (data->rh_alarm.low_alarm) {
> 		*val = (measurement < min_hyst) ? 1 : 0;
>
> CPU2 in drivers/hwmon/chipcap2.c:cc2_low_interrupt() {
> 		cc2->rh_alarm.low_alarm = true;
> }
>
> CPU1 continues:
> 		data->rh_alarm.low_alarm = *val;
> 	} else {
> 		*val = 0;
> 	}
> 	...
> }
>
> The interrupt's update will be overwritten with 0 and permanently lost. The
> hwmon subsystem guidelines require drivers to implement locking for interrupt
> handling and sysfs attributes, recommending the use of hwmon_lock() and
> hwmon_unlock().
>
> Could this concurrent access to data->rh_alarm.low_alarm be protected?

I agree with Sashiko's report about the concurrency issue. If an
interrupt is triggered right after checking data->rh_alarm.low_alarm,
the status would be 0 instead of 1, if no prior interrupts were
triggered.

Sashiko only reported this issue for the low alarm, but the same applies
for the high alarm, which is independent and has a dedicated signal.
I am not sure about using hwmon_lock()/hwmon_unlock() for this, as it
serializes all kind of accesses and not only the ones concerning the
interrupt status. That might add some extra delay with many accesses at
the same time, although the fix would be simpler.

The most optimal way might be using 2 different locks for the two
interrupts, as they happen in different lanes and don't share data.
If that is ok, I can prepare a patch to test it on real hardware and send
it upstream.

Best regards,
Javier