power: supply: ucs1002: fix some health status issues
authorLucas Stach <l.stach@pengutronix.de>
Wed, 30 Sep 2020 08:40:47 +0000 (10:40 +0200)
committerSebastian Reichel <sebastian.reichel@collabora.com>
Wed, 30 Sep 2020 22:18:05 +0000 (00:18 +0200)
commit81196e2e57fc5b88f6b8ca98372a3dde047aa49d
tree0fd685763f63cc1e45821a98bcaa732c3cced176
parent3c8b5fb9983b7c7eb2e3557d687a3613288e0780
power: supply: ucs1002: fix some health status issues

Some fault events like the over-current condition will get resolved
by the hardware, by e.g. disabling the port. As the status in the
interrupt status register is cleared on read when the fault is resolved,
the sysfs health property will only contain the correct health status
for the first time it is read after such an event, even if the actual
fault condition (like a VBUS short) still persists. To reflect this
properly in the property we cache the last health status and only update
the cache when a actual change happens, i.e. the ERR bit in the status
register flips, as this one properly reflects a continued fault condition.

The ALERT pin however, is not driven by the ERR status, but by the actual
fault status, so the pin will change back to it's default state when the
hardware has automatically resolved the fault by cutting the power. Thus
we never get an IRQ when the actual fault condition has been resolved and
the ERR status bit has been cleared in auto-recovery mode. To get this
information we need to poll the interrupt status register after some time
to see if the fault is gone and update our cache in that case.

To avoid any additional locking, we handle both paths (IRQ firing and
delayed polling) through the same single-threaded delayed work.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
drivers/power/supply/ucs1002_power.c