Re: [PATCH v3 00/11] hwmon: chipcap2: various bug fixes

[Guenter Roeck]

On 10/14/26 10:33, Javier Carrasco wrote:
> The original issue (race condition for the alarms) was found by Sashiko[1]
> when an unrelated patch affected chipcap2.c. The issue is real as the
> access to the variables is not protected by any locking mechanism
> although 2 different sources (threaded interrupts and sysfs) could
> modify them.
>
> In further iterations Sashiko found new issues[2] that have been added to
> the series:
>
> - Fix be16 data handling.
> - Defer probe when the IRQs are not available yet.
> - IRQ teardown ordering: split the current implementation to provide the
>    available interrupts before registering the hwmon device, and register
>    the IRQs after the hwmon device has been registered.
> - Disable the device after the hwmon device has been unregistered.
> - Enable IRQ processing when the regulator is already enabled.
> - Balance regulator counter.
> - Do not discard the pending alarms when the device is disabled.
> - Reset the completion to account for counter > 1.
> - IRQ serialization and synchronization.
>
> The last item required a dedicated mutex because the hwmon_lock was not
> suitable to close the gaps where an interrupt might go unnoticed because
> there is some dependency between the data read and the interrupt
> generation, and also in the completion mechanism. I went through the
> different alternatives with a combination of local Sashiko and a second
> AI agent, and discarded some complex solutions to close gaps that are
> more theoretical than practical e.g. the interrupt was fired, but it did
> not reach the controller due to nested GPIO expanders. I added the
> Assisted-by: tags to those patches accordingly, although it seems that
> this requirement will soon vanish.
>
> Additionally, a harmless off-by-one in a for loop has been fixed to save
> ~80 ms after the last failed command retry, and the error reporting has
> been fixed to show the right issue. These two ones have not been tagged
> for stable as they are only meant to improve reaction time and logging
> inaccuracies after a command fails. The deferred probe does not have the
> stable tag as it is just a reaction if interrupts were provided but
> still not available. Of course, I can add the tags to all patches
> if required.
>
> The fixes have been validated on real hardware with an Amphenol
> ChipCap 2 CC2D23S sensor.

Series applied. I assume any valid issues reported by Sashiko will be fixed
separately.

Thanks,
Guenter