Re: [PATCH v5 3/3] arm64: defconfig: Enable drivers for BeagleBadge

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The sht4x hwmon driver registers sysfs attributes outside the core hwmon locking but fails to implement its own locks, leading to race conditions on driver state and I2C communications.
--

commit f3062b5d533df41f751a64a30b3c9b20072c21e4
Author: Judith Mendez <jm@ti.com>

arm64: defconfig: Enable drivers for BeagleBadge

This commit enables drivers used on the BeagleBadge as modules in the
arm64 defconfig. This includes drivers for the LED PWM Multicolor,
MCP SPI IO Expander, Seven Segment display GPIO, and Temperature Sensor.

Link: https://www.beagleboard.org/boards/beaglebadge

> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index d905a0777f939..5cfb7f6f2ae78 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig

[ ... ]

> @@ -766,6 +767,7 @@ CONFIG_SENSORS_LM90=m
>  CONFIG_SENSORS_PWM_FAN=m
>  CONFIG_SENSORS_RASPBERRYPI_HWMON=m
>  CONFIG_SENSORS_SL28CPLD=m
> +CONFIG_SENSORS_SHT4x=m
[Severity: High]
This is a pre-existing issue, but does the sht4x driver lack locking for
its sysfs attributes?

The hardware monitoring subsystem guidelines state that drivers must
implement their own locking for attributes registered outside the core,
such as those in extra_groups. The sht4x driver registers heater attributes
like heater_enable via extra_groups but does not appear to provide locking.

If a write to heater_enable occurs during the usleep_range() of a
temperature read:

sht4x_read_values() {
    ret = i2c_master_send(client, cmd, SHT4X_CMD_LEN);
    ...
    usleep_range(SHT4X_MEAS_DELAY_HPM, ...);
    ...
    ret = i2c_master_recv(client, raw_data, SHT4X_RESPONSE_LENGTH);
}

Concurrent with a write to the heater:

heater_enable_store() {
    ret = i2c_master_send(data->client, &cmd, SHT4X_CMD_LEN);
    ...
    data->heating_complete = jiffies + msecs_to_jiffies(heating_time_bound);
    data->data_pending = true;
}

Could this interleave I2C traffic and cause the subsequent
i2c_master_recv() to read the wrong response or abort the measurement?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526235417.1326187-1-jm@ti.com?part=3