hwmon: (acpi_power_meter) Prevent spurious power alarm when power is unknown

According to the ACPI specification (Section 10.4.3 _PMM), if an error
occurs while obtaining the power meter reading or if the value is not
available, _PMM returns an integer with all bits set (U32_MAX or
U64_MAX).

In get_power_alarm_state(), update_meter() stores this unknown sentinel
value in resource->power and returns 0. Unlike the hwmon_power_average
handler in power_meter_read(), get_power_alarm_state() does not check
resource->power against UNKNOWN_POWER_32 or UNKNOWN_POWER_64 before
comparing resource->power > resource->cap. Because the sentinel is a
large unsigned integer, the comparison evaluates to true for any valid
cap, falsely reporting an active power alarm to userspace.

Furthermore, get_power_alarm_state() writes resource->power > resource->cap
back into resource->power_alarm, re-latching polled software comparisons
as if a hardware METER_NOTIFY_CAPPING event had occurred and causing the
next power1_alarm read to falsely report an alarm even after power drops
below cap or becomes unknown.

In addition, alarm attributes should not return error codes when the
alarm status cannot be determined; an inconclusive alarm state should
report 0 (no alarm, no error).

Convert get_power_alarm_state() to return a boolean alarm state. Consume
and clear any latched hardware capping notification in
resource->power_alarm without re-latching software comparisons, and
return false (0, no alarm) when no notification was latched and
resource->power is unknown or updating the meter or cap reading fails.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: de584afa5e18 ("hwmon driver for ACPI 4.0 power meters")
Fixes: 7532e68f5d8f ("hwmon: (acpi_power_meter) Fix uninitialized variables")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

0 files changed, 0 insertions, 0 deletions