On Fri, Apr 12, 2024 at 10:27:56PM +0200, Armin Wolf wrote:I see, however it seems that some ACPI implementations also return a fan speed of 0xffffffff
There should be no fault attributes unless a real faultHi,+ case hwmon_fan_fault:Is it documented that this is indeed a fault (broken fan) ?
+ *val = (fst.speed == FAN_SPEED_UNAVAILABLE);
it actually means that the fan does not support speed reporting.
FAN_POWER_UNAVAILABLE signals that the power value is not supported.+ return 0;Is it documented that this is indeed a power supply failure ?
+ default:
+ break;
+ }
+ break;
+ case hwmon_power:
+ fps = acpi_fan_get_current_fps(fan, fst.control);
+ if (!fps)
+ return -ENODATA;
+
+ switch (attr) {
+ case hwmon_power_input:
+ if (fps->power == FAN_POWER_UNAVAILABLE)
+ return -ENODATA;
+
+ if (fps->power > LONG_MAX / MICROWATT_PER_MILLIWATT)
+ return -EOVERFLOW;
+
+ *val = fps->power * MICROWATT_PER_MILLIWATT;
+ return 0;
+ case hwmon_power_fault:
+ *val = (fps->power == FAN_POWER_UNAVAILABLE);
What if the value is simply not reported ? "UNAVAILABLE" is not
commonly associated with a "fault".
Guenter
Would it be more suitable to drop the fault attributes and just return -ENODATA in such a case?
is reported, and if power reporting is not supported the
hwmon_power_input attribute should not even be created.
The same really applies to the fan speed atribute: If reading
the fan speed is not supported, the attribute should not even
exist.
Guenter