[PATCH v2 0/4] hwmon: (ina2xx) Decouple in0 and curr1 alarms

[Jared Kangas]

The in0 and curr1 alarms in the ina2xx driver are both based on shunt
voltage in the hardware, which causes unexpected behavior when reading
the two inputs' alarms:

1. Both alarms may read back 1, even though only one is set.

2. The active alarm may read back 0 even if the limit was reached due to
   the use of alert latching. If the inactive alarm is read, it clears
   the active alarm, and the alarm may not be set before the next read:

        # echo 1800 >curr1_lcrit
        # head {in0,curr1}_lcrit_alarm
        ==> in0_lcrit_alarm <==
        1

        ==> curr1_lcrit_alarm <==
        0

To address this, track the active alarm's type in the driver, and when
reading alarms, return early without polling the hardware if the alarm
being read is inactive.

Patch 1 is a locking fix reported by Sashiko in [1], followed by some
prep work in 2-3 to simplify the fix in patch 4.

[1]: https://lore.kernel.org/all/20260729162836.89BDF1F00A3A@xxxxxxxxxxxxxxx/

Signed-off-by: Jared Kangas <jkangas@xxxxxxxxxx>
---
Changes in v2:
- Squash v1's patches 3/4 and 4/4 into v2's 4/4
- Split active_alert assignment in alert_limit_write in case of
  failures between zeroing old mask and writing new mask.
- Add hwmon_lock in shunt_resistor_show
- Add #include <linux/bitops.h>
- Touch up code comments and commit descriptions
- Link to v1: https://lore.kernel.org/r/20260729-upstream-ina2xx-in0-curr1-alarms-v1-0-349f7b2f1df8@xxxxxxxxxx

---
Jared Kangas (4):
      hwmon: (ina2xx) Acquire hwmon_lock in shunt_resistor_show()
      hwmon: (ina2xx) Parameterize ina2xx_data in ina226_alert_read()
      hwmon: (ina2xx) Replace masks with enum in alert functions
      hwmon: (ina2xx) Decouple in0 and curr1 alarms

 drivers/hwmon/ina2xx.c | 163 +++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 136 insertions(+), 27 deletions(-)
---
base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
change-id: 20260724-upstream-ina2xx-in0-curr1-alarms-f85e7d692fdf

Best regards,
-- 
Jared Kangas <jkangas@xxxxxxxxxx>