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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The threaded interrupt handlers modify alarm state flags without locking, creating a race condition with sysfs reads that can result in lost alarm events.
--

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

dt-bindings: hwmon: chipcap2: Add label property

This commit adds support for an optional label property similar to other
hwmon devices. This allows assigning distinct names to each CHIPCAP2
sensor instance on boards with multiple sensors.

> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> index 17351fdbefce6..56b0cecfca5fb 100644
> --- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> @@ -45,6 +45,8 @@ properties:
>        - const: low
>        - const: high
>  
> +  label: true
> +
>    vdd-supply:

[ ... ]

While reviewing the hwmon driver code for this hardware, I noticed a
potential locking issue in the interrupt handling.

> --- a/drivers/hwmon/chipcap2.c
> +++ b/drivers/hwmon/chipcap2.c
[ ... ]
> static irqreturn_t cc2_low_interrupt(int irq, void *data)
> {
> 	struct cc2_data *cc2 = data;
> 
> 	if (cc2->process_irqs) {
> 		hwmon_notify_event(cc2->hwmon, hwmon_humidity,
> 				   hwmon_humidity_min_alarm, CC2_CHAN_HUMIDITY);
> 		cc2->rh_alarm.low_alarm = true;
                ^^^^

[Severity: High]
This isn't a bug introduced by this patch, but the threaded interrupt
handler modifies the min alarm flag without acquiring a lock. Could this
create a race condition where an active alarm gets overwritten?

> 	}
> 
> 	return IRQ_HANDLED;
> }
> 
> static irqreturn_t cc2_high_interrupt(int irq, void *data)
> {
> 	struct cc2_data *cc2 = data;
> 
> 	if (cc2->process_irqs) {
> 		hwmon_notify_event(cc2->hwmon, hwmon_humidity,
> 				   hwmon_humidity_max_alarm, CC2_CHAN_HUMIDITY);
> 		cc2->rh_alarm.high_alarm = true;
                ^^^^

[Severity: High]
This is a pre-existing issue, but the max alarm flag is also modified
here without locking.

> 	}
> 
> 	return IRQ_HANDLED;
> }
> 
> static int cc2_humidity_min_alarm_status(struct cc2_data *data, long *val)
> {
> 	long measurement, min_hyst;
> 	int ret;
> 
> 	ret = cc2_read_hyst_and_measure(data, CC2_R_ALARM_L_OFF, &min_hyst,
> 					&measurement);
> 	if (ret < 0)
> 		return ret;
> 
> 	if (data->rh_alarm.low_alarm) {
> 		*val = (measurement < min_hyst) ? 1 : 0;
> 		data->rh_alarm.low_alarm = *val;
                ^^^^

[Severity: High]
This isn't a bug introduced by this patch, but the sysfs read thread
performs an unprotected read-modify-write on the alarm state flag here.

If a sysfs read of the alarm status evaluates the current measurement
over the I2C bus, and cc2_low_interrupt() concurrently receives an
alarm setting low_alarm to true, could the sysfs thread subsequently
overwrite the active alarm flag with 0 based on stale measurement data?

The hwmon subsystem documentation mentions that hwmon_lock() or custom
locking should be used to serialize sysfs operations with interrupt
handling.

> 	} else {
> 		*val = 0;
> 	}
> 
> 	return 0;
> }
> 
> static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
> {
> 	long measurement, max_hyst;
> 	int ret;
> 
> 	ret = cc2_read_hyst_and_measure(data, CC2_R_ALARM_H_OFF, &max_hyst,
> 					&measurement);
> 	if (ret < 0)
> 		return ret;
> 
> 	if (data->rh_alarm.high_alarm) {
> 		*val = (measurement > max_hyst) ? 1 : 0;
> 		data->rh_alarm.high_alarm = *val;
                ^^^^

[Severity: High]
This is a pre-existing issue, but the max alarm sysfs read also writes
back the max alarm flag without locking. Does this present the same risk
of lost alarm events if cc2_high_interrupt() runs concurrently?

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