Currently, the driver does only support a custom sysfs
interface to allow userspace to read the fan speed.
Add support for the standard hwmon interface so users
can read the fan speed with standard tools like "sensors".
Tested with a custom ACPI SSDT.
Signed-off-by: Armin Wolf <[email protected]>
---
Changes since v5:
- fix coding style issues
- replace double break with return
- add missing includes
Changes since v4:
- fix spelling issues
- check power values for overflow condition too
Changes since v3:
- drop fault attrs
- rework initialization
Changes since v2:
- add support for fanX_target and power attrs
Changes since v1:
- fix undefined reference error
- fix fan speed validation
- coding style fixes
- clarify that the changes are compile-tested only
- add hwmon maintainers to cc list
---
drivers/acpi/Makefile | 1 +
drivers/acpi/fan.h | 9 +++
drivers/acpi/fan_core.c | 4 +
drivers/acpi/fan_hwmon.c | 169 +++++++++++++++++++++++++++++++++++++++
4 files changed, 183 insertions(+)
create mode 100644 drivers/acpi/fan_hwmon.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 39ea5cfa8326..61ca4afe83dc 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_ACPI_TINY_POWER_BUTTON) += tiny-power-button.o
obj-$(CONFIG_ACPI_FAN) += fan.o
fan-objs := fan_core.o
fan-objs += fan_attr.o
+fan-$(CONFIG_HWMON) += fan_hwmon.o
obj-$(CONFIG_ACPI_VIDEO) += video.o
obj-$(CONFIG_ACPI_TAD) += acpi_tad.o
diff --git a/drivers/acpi/fan.h b/drivers/acpi/fan.h
index f89d19c922dc..db25a3898af7 100644
--- a/drivers/acpi/fan.h
+++ b/drivers/acpi/fan.h
@@ -10,6 +10,8 @@
#ifndef _ACPI_FAN_H_
#define _ACPI_FAN_H_
+#include <linux/kconfig.h>
+
#define ACPI_FAN_DEVICE_IDS \
{"INT3404", }, /* Fan */ \
{"INTC1044", }, /* Fan for Tiger Lake generation */ \
@@ -57,4 +59,11 @@ struct acpi_fan {
int acpi_fan_get_fst(struct acpi_device *device, struct acpi_fan_fst *fst);
int acpi_fan_create_attributes(struct acpi_device *device);
void acpi_fan_delete_attributes(struct acpi_device *device);
+
+#if IS_REACHABLE(CONFIG_HWMON)
+int devm_acpi_fan_create_hwmon(struct acpi_device *device);
+#else
+static inline int devm_acpi_fan_create_hwmon(struct acpi_device *device) { return 0; };
+#endif
+
#endif
diff --git a/drivers/acpi/fan_core.c b/drivers/acpi/fan_core.c
index ff72e4ef8738..7cea4495f19b 100644
--- a/drivers/acpi/fan_core.c
+++ b/drivers/acpi/fan_core.c
@@ -336,6 +336,10 @@ static int acpi_fan_probe(struct platform_device *pdev)
if (result)
return result;
+ result = devm_acpi_fan_create_hwmon(device);
+ if (result)
+ return result;
+
result = acpi_fan_create_attributes(device);
if (result)
return result;
diff --git a/drivers/acpi/fan_hwmon.c b/drivers/acpi/fan_hwmon.c
new file mode 100644
index 000000000000..34a524c285a5
--- /dev/null
+++ b/drivers/acpi/fan_hwmon.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hwmon interface for the ACPI Fan driver.
+ *
+ * Copyright (C) 2024 Armin Wolf <[email protected]>
+ */
+
+#include <linux/acpi.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/limits.h>
+#include <linux/units.h>
+
+#include "fan.h"
+
+/* Returned when the ACPI fan does not support speed reporting */
+#define FAN_SPEED_UNAVAILABLE U32_MAX
+#define FAN_POWER_UNAVAILABLE U32_MAX
+
+static struct acpi_fan_fps *acpi_fan_get_current_fps(struct acpi_fan *fan, u64 control)
+{
+ unsigned int i;
+
+ for (i = 0; i < fan->fps_count; i++) {
+ if (fan->fps[i].control == control)
+ return &fan->fps[i];
+ }
+
+ return NULL;
+}
+
+static umode_t acpi_fan_is_visible(const void *drvdata, enum hwmon_sensor_types type, u32 attr,
+ int channel)
+{
+ const struct acpi_fan *fan = drvdata;
+ unsigned int i;
+
+ switch (type) {
+ case hwmon_fan:
+ switch (attr) {
+ case hwmon_fan_input:
+ return 0444;
+ case hwmon_fan_target:
+ /*
+ * When in fine grain control mode, not every fan control value
+ * has an associated fan performance state.
+ */
+ if (fan->fif.fine_grain_ctrl)
+ return 0;
+
+ return 0444;
+ default:
+ return 0;
+ }
+ case hwmon_power:
+ switch (attr) {
+ case hwmon_power_input:
+ /*
+ * When in fine grain control mode, not every fan control value
+ * has an associated fan performance state.
+ */
+ if (fan->fif.fine_grain_ctrl)
+ return 0;
+
+ /*
+ * When all fan performance states contain no valid power data,
+ * when the associated attribute should not be created.
+ */
+ for (i = 0; i < fan->fps_count; i++) {
+ if (fan->fps[i].power != FAN_POWER_UNAVAILABLE)
+ return 0444;
+ }
+
+ return 0;
+ default:
+ return 0;
+ }
+ default:
+ return 0;
+ }
+}
+
+static int acpi_fan_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel,
+ long *val)
+{
+ struct acpi_device *adev = to_acpi_device(dev->parent);
+ struct acpi_fan *fan = dev_get_drvdata(dev);
+ struct acpi_fan_fps *fps;
+ struct acpi_fan_fst fst;
+ int ret;
+
+ ret = acpi_fan_get_fst(adev, &fst);
+ if (ret < 0)
+ return ret;
+
+ switch (type) {
+ case hwmon_fan:
+ switch (attr) {
+ case hwmon_fan_input:
+ if (fst.speed == FAN_SPEED_UNAVAILABLE)
+ return -ENODATA;
+
+ if (fst.speed > LONG_MAX)
+ return -EOVERFLOW;
+
+ *val = fst.speed;
+ return 0;
+ case hwmon_fan_target:
+ fps = acpi_fan_get_current_fps(fan, fst.control);
+ if (!fps)
+ return -ENODATA;
+
+ if (fps->speed > LONG_MAX)
+ return -EOVERFLOW;
+
+ *val = fps->speed;
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ case hwmon_power:
+ switch (attr) {
+ case hwmon_power_input:
+ fps = acpi_fan_get_current_fps(fan, fst.control);
+ if (!fps)
+ return -ENODATA;
+
+ 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;
+ default:
+ return -EOPNOTSUPP;
+ }
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops acpi_fan_ops = {
+ .is_visible = acpi_fan_is_visible,
+ .read = acpi_fan_read,
+};
+
+static const struct hwmon_channel_info * const acpi_fan_info[] = {
+ HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_TARGET),
+ HWMON_CHANNEL_INFO(power, HWMON_P_INPUT),
+ NULL
+};
+
+static const struct hwmon_chip_info acpi_fan_chip_info = {
+ .ops = &acpi_fan_ops,
+ .info = acpi_fan_info,
+};
+
+int devm_acpi_fan_create_hwmon(struct acpi_device *device)
+{
+ struct acpi_fan *fan = acpi_driver_data(device);
+ struct device *hdev;
+
+ hdev = devm_hwmon_device_register_with_info(&device->dev, "acpi_fan", fan,
+ &acpi_fan_chip_info, NULL);
+ return PTR_ERR_OR_ZERO(hdev);
+}
--
2.39.2
On Mon, Apr 22, 2024 at 9:58 PM Armin Wolf <[email protected]> wrote:
>
> Currently, the driver does only support a custom sysfs
> interface to allow userspace to read the fan speed.
> Add support for the standard hwmon interface so users
> can read the fan speed with standard tools like "sensors".
>
> Tested with a custom ACPI SSDT.
>
> Signed-off-by: Armin Wolf <[email protected]>
I need Guenter to tell me that this is fine with him.
Also please see one nit below.
> ---
> Changes since v5:
> - fix coding style issues
> - replace double break with return
> - add missing includes
>
> Changes since v4:
> - fix spelling issues
> - check power values for overflow condition too
>
> Changes since v3:
> - drop fault attrs
> - rework initialization
>
> Changes since v2:
> - add support for fanX_target and power attrs
>
> Changes since v1:
> - fix undefined reference error
> - fix fan speed validation
> - coding style fixes
> - clarify that the changes are compile-tested only
> - add hwmon maintainers to cc list
> ---
> drivers/acpi/Makefile | 1 +
> drivers/acpi/fan.h | 9 +++
> drivers/acpi/fan_core.c | 4 +
> drivers/acpi/fan_hwmon.c | 169 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 183 insertions(+)
> create mode 100644 drivers/acpi/fan_hwmon.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 39ea5cfa8326..61ca4afe83dc 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -77,6 +77,7 @@ obj-$(CONFIG_ACPI_TINY_POWER_BUTTON) += tiny-power-button.o
> obj-$(CONFIG_ACPI_FAN) += fan.o
> fan-objs := fan_core.o
> fan-objs += fan_attr.o
> +fan-$(CONFIG_HWMON) += fan_hwmon.o
>
> obj-$(CONFIG_ACPI_VIDEO) += video.o
> obj-$(CONFIG_ACPI_TAD) += acpi_tad.o
> diff --git a/drivers/acpi/fan.h b/drivers/acpi/fan.h
> index f89d19c922dc..db25a3898af7 100644
> --- a/drivers/acpi/fan.h
> +++ b/drivers/acpi/fan.h
> @@ -10,6 +10,8 @@
> #ifndef _ACPI_FAN_H_
> #define _ACPI_FAN_H_
>
> +#include <linux/kconfig.h>
> +
> #define ACPI_FAN_DEVICE_IDS \
> {"INT3404", }, /* Fan */ \
> {"INTC1044", }, /* Fan for Tiger Lake generation */ \
> @@ -57,4 +59,11 @@ struct acpi_fan {
> int acpi_fan_get_fst(struct acpi_device *device, struct acpi_fan_fst *fst);
> int acpi_fan_create_attributes(struct acpi_device *device);
> void acpi_fan_delete_attributes(struct acpi_device *device);
> +
> +#if IS_REACHABLE(CONFIG_HWMON)
> +int devm_acpi_fan_create_hwmon(struct acpi_device *device);
> +#else
> +static inline int devm_acpi_fan_create_hwmon(struct acpi_device *device) { return 0; };
> +#endif
> +
> #endif
> diff --git a/drivers/acpi/fan_core.c b/drivers/acpi/fan_core.c
> index ff72e4ef8738..7cea4495f19b 100644
> --- a/drivers/acpi/fan_core.c
> +++ b/drivers/acpi/fan_core.c
> @@ -336,6 +336,10 @@ static int acpi_fan_probe(struct platform_device *pdev)
> if (result)
> return result;
>
> + result = devm_acpi_fan_create_hwmon(device);
> + if (result)
> + return result;
> +
> result = acpi_fan_create_attributes(device);
> if (result)
> return result;
> diff --git a/drivers/acpi/fan_hwmon.c b/drivers/acpi/fan_hwmon.c
> new file mode 100644
> index 000000000000..34a524c285a5
> --- /dev/null
> +++ b/drivers/acpi/fan_hwmon.c
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Hwmon interface for the ACPI Fan driver.
> + *
> + * Copyright (C) 2024 Armin Wolf <[email protected]>
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/limits.h>
> +#include <linux/units.h>
> +
> +#include "fan.h"
> +
> +/* Returned when the ACPI fan does not support speed reporting */
> +#define FAN_SPEED_UNAVAILABLE U32_MAX
> +#define FAN_POWER_UNAVAILABLE U32_MAX
> +
> +static struct acpi_fan_fps *acpi_fan_get_current_fps(struct acpi_fan *fan, u64 control)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < fan->fps_count; i++) {
> + if (fan->fps[i].control == control)
> + return &fan->fps[i];
> + }
> +
> + return NULL;
> +}
> +
> +static umode_t acpi_fan_is_visible(const void *drvdata, enum hwmon_sensor_types type, u32 attr,
> + int channel)
> +{
> + const struct acpi_fan *fan = drvdata;
> + unsigned int i;
> +
> + switch (type) {
> + case hwmon_fan:
> + switch (attr) {
> + case hwmon_fan_input:
> + return 0444;
> + case hwmon_fan_target:
> + /*
> + * When in fine grain control mode, not every fan control value
> + * has an associated fan performance state.
> + */
> + if (fan->fif.fine_grain_ctrl)
> + return 0;
> +
> + return 0444;
> + default:
> + return 0;
> + }
> + case hwmon_power:
> + switch (attr) {
> + case hwmon_power_input:
> + /*
> + * When in fine grain control mode, not every fan control value
> + * has an associated fan performance state.
> + */
> + if (fan->fif.fine_grain_ctrl)
> + return 0;
> +
> + /*
> + * When all fan performance states contain no valid power data,
> + * when the associated attribute should not be created.
> + */
> + for (i = 0; i < fan->fps_count; i++) {
> + if (fan->fps[i].power != FAN_POWER_UNAVAILABLE)
> + return 0444;
> + }
> +
> + return 0;
> + default:
> + return 0;
> + }
> + default:
> + return 0;
> + }
> +}
> +
> +static int acpi_fan_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel,
> + long *val)
> +{
> + struct acpi_device *adev = to_acpi_device(dev->parent);
> + struct acpi_fan *fan = dev_get_drvdata(dev);
> + struct acpi_fan_fps *fps;
> + struct acpi_fan_fst fst;
> + int ret;
> +
> + ret = acpi_fan_get_fst(adev, &fst);
> + if (ret < 0)
> + return ret;
> +
> + switch (type) {
> + case hwmon_fan:
> + switch (attr) {
> + case hwmon_fan_input:
> + if (fst.speed == FAN_SPEED_UNAVAILABLE)
> + return -ENODATA;
> +
> + if (fst.speed > LONG_MAX)
> + return -EOVERFLOW;
> +
> + *val = fst.speed;
> + return 0;
> + case hwmon_fan_target:
> + fps = acpi_fan_get_current_fps(fan, fst.control);
> + if (!fps)
> + return -ENODATA;
> +
> + if (fps->speed > LONG_MAX)
> + return -EOVERFLOW;
> +
> + *val = fps->speed;
> + return 0;
> + default:
> + return -EOPNOTSUPP;
> + }
> + case hwmon_power:
> + switch (attr) {
> + case hwmon_power_input:
> + fps = acpi_fan_get_current_fps(fan, fst.control);
> + if (!fps)
> + return -ENODATA;
> +
> + 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;
> + default:
> + return -EOPNOTSUPP;
> + }
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static const struct hwmon_ops acpi_fan_ops = {
> + .is_visible = acpi_fan_is_visible,
> + .read = acpi_fan_read,
> +};
I would add "hwmon" to the names of functions and variables related to
hwmon. Something like
+static const struct hwmon_ops acpi_fan_hwmon_ops = {
+ .is_visible = acpi_fan_hwmon_is_visible,
+ .read = acpi_fan_hwmon_read,
+};
Otherwise, it looks fine to me.
> +
> +static const struct hwmon_channel_info * const acpi_fan_info[] = {
> + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_TARGET),
> + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT),
> + NULL
> +};
> +
> +static const struct hwmon_chip_info acpi_fan_chip_info = {
> + .ops = &acpi_fan_ops,
> + .info = acpi_fan_info,
> +};
> +
> +int devm_acpi_fan_create_hwmon(struct acpi_device *device)
> +{
> + struct acpi_fan *fan = acpi_driver_data(device);
> + struct device *hdev;
> +
> + hdev = devm_hwmon_device_register_with_info(&device->dev, "acpi_fan", fan,
> + &acpi_fan_chip_info, NULL);
> + return PTR_ERR_OR_ZERO(hdev);
> +}
> --
On 4/24/24 12:01, Rafael J. Wysocki wrote:
> On Mon, Apr 22, 2024 at 9:58 PM Armin Wolf <[email protected]> wrote:
>>
>> Currently, the driver does only support a custom sysfs
>> interface to allow userspace to read the fan speed.
>> Add support for the standard hwmon interface so users
>> can read the fan speed with standard tools like "sensors".
>>
>> Tested with a custom ACPI SSDT.
>>
>> Signed-off-by: Armin Wolf <[email protected]>
>
> I need Guenter to tell me that this is fine with him.
>
Sorry, I have no idea. Se below.
> Also please see one nit below.
>
>> ---
>> Changes since v5:
>> - fix coding style issues
>> - replace double break with return
>> - add missing includes
>>
>> Changes since v4:
>> - fix spelling issues
>> - check power values for overflow condition too
>>
>> Changes since v3:
>> - drop fault attrs
>> - rework initialization
>>
>> Changes since v2:
>> - add support for fanX_target and power attrs
>>
>> Changes since v1:
>> - fix undefined reference error
>> - fix fan speed validation
>> - coding style fixes
>> - clarify that the changes are compile-tested only
>> - add hwmon maintainers to cc list
>> ---
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/fan.h | 9 +++
>> drivers/acpi/fan_core.c | 4 +
>> drivers/acpi/fan_hwmon.c | 169 +++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 183 insertions(+)
>> create mode 100644 drivers/acpi/fan_hwmon.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 39ea5cfa8326..61ca4afe83dc 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -77,6 +77,7 @@ obj-$(CONFIG_ACPI_TINY_POWER_BUTTON) += tiny-power-button.o
>> obj-$(CONFIG_ACPI_FAN) += fan.o
>> fan-objs := fan_core.o
>> fan-objs += fan_attr.o
>> +fan-$(CONFIG_HWMON) += fan_hwmon.o
>>
>> obj-$(CONFIG_ACPI_VIDEO) += video.o
>> obj-$(CONFIG_ACPI_TAD) += acpi_tad.o
>> diff --git a/drivers/acpi/fan.h b/drivers/acpi/fan.h
>> index f89d19c922dc..db25a3898af7 100644
>> --- a/drivers/acpi/fan.h
>> +++ b/drivers/acpi/fan.h
>> @@ -10,6 +10,8 @@
>> #ifndef _ACPI_FAN_H_
>> #define _ACPI_FAN_H_
>>
>> +#include <linux/kconfig.h>
>> +
>> #define ACPI_FAN_DEVICE_IDS \
>> {"INT3404", }, /* Fan */ \
>> {"INTC1044", }, /* Fan for Tiger Lake generation */ \
>> @@ -57,4 +59,11 @@ struct acpi_fan {
>> int acpi_fan_get_fst(struct acpi_device *device, struct acpi_fan_fst *fst);
>> int acpi_fan_create_attributes(struct acpi_device *device);
>> void acpi_fan_delete_attributes(struct acpi_device *device);
>> +
>> +#if IS_REACHABLE(CONFIG_HWMON)
>> +int devm_acpi_fan_create_hwmon(struct acpi_device *device);
>> +#else
>> +static inline int devm_acpi_fan_create_hwmon(struct acpi_device *device) { return 0; };
>> +#endif
>> +
>> #endif
>> diff --git a/drivers/acpi/fan_core.c b/drivers/acpi/fan_core.c
>> index ff72e4ef8738..7cea4495f19b 100644
>> --- a/drivers/acpi/fan_core.c
>> +++ b/drivers/acpi/fan_core.c
>> @@ -336,6 +336,10 @@ static int acpi_fan_probe(struct platform_device *pdev)
>> if (result)
>> return result;
>>
>> + result = devm_acpi_fan_create_hwmon(device);
>> + if (result)
>> + return result;
>> +
>> result = acpi_fan_create_attributes(device);
>> if (result)
>> return result;
>> diff --git a/drivers/acpi/fan_hwmon.c b/drivers/acpi/fan_hwmon.c
>> new file mode 100644
>> index 000000000000..34a524c285a5
>> --- /dev/null
>> +++ b/drivers/acpi/fan_hwmon.c
>> @@ -0,0 +1,169 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Hwmon interface for the ACPI Fan driver.
>> + *
>> + * Copyright (C) 2024 Armin Wolf <[email protected]>
>> + */
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/limits.h>
>> +#include <linux/units.h>
>> +
>> +#include "fan.h"
>> +
>> +/* Returned when the ACPI fan does not support speed reporting */
>> +#define FAN_SPEED_UNAVAILABLE U32_MAX
>> +#define FAN_POWER_UNAVAILABLE U32_MAX
>> +
>> +static struct acpi_fan_fps *acpi_fan_get_current_fps(struct acpi_fan *fan, u64 control)
>> +{
>> + unsigned int i;
>> +
>> + for (i = 0; i < fan->fps_count; i++) {
>> + if (fan->fps[i].control == control)
>> + return &fan->fps[i];
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static umode_t acpi_fan_is_visible(const void *drvdata, enum hwmon_sensor_types type, u32 attr,
>> + int channel)
>> +{
>> + const struct acpi_fan *fan = drvdata;
>> + unsigned int i;
>> +
>> + switch (type) {
>> + case hwmon_fan:
>> + switch (attr) {
>> + case hwmon_fan_input:
>> + return 0444;
>> + case hwmon_fan_target:
>> + /*
>> + * When in fine grain control mode, not every fan control value
>> + * has an associated fan performance state.
>> + */
>> + if (fan->fif.fine_grain_ctrl)
>> + return 0;
>> +
>> + return 0444;
>> + default:
>> + return 0;
>> + }
>> + case hwmon_power:
>> + switch (attr) {
>> + case hwmon_power_input:
>> + /*
>> + * When in fine grain control mode, not every fan control value
>> + * has an associated fan performance state.
>> + */
>> + if (fan->fif.fine_grain_ctrl)
>> + return 0;
>> +
>> + /*
>> + * When all fan performance states contain no valid power data,
>> + * when the associated attribute should not be created.
>> + */
>> + for (i = 0; i < fan->fps_count; i++) {
>> + if (fan->fps[i].power != FAN_POWER_UNAVAILABLE)
>> + return 0444;
>> + }
Is this all or nothing ? Doesn't this depend on the channel ? It looks
as if the first fan supports reporting the power, attributes are
generated for all fans even if the others don't support it
To me it looks like there are situations where individual
fans will still persistently report -ENODATA for fan speed, power,
or both. I don't know the specification well enough (not at all, really)
to be able to determine if this makes sense. Normally, -ENODATA should be
reserved for "value temporarily not available". I am not sure if that is
the case here.
Guenter
>> +
>> + return 0;
>> + default:
>> + return 0;
>> + }
>> + default:
>> + return 0;
>> + }
>> +}
>> +
>> +static int acpi_fan_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel,
>> + long *val)
>> +{
>> + struct acpi_device *adev = to_acpi_device(dev->parent);
>> + struct acpi_fan *fan = dev_get_drvdata(dev);
>> + struct acpi_fan_fps *fps;
>> + struct acpi_fan_fst fst;
>> + int ret;
>> +
>> + ret = acpi_fan_get_fst(adev, &fst);
>> + if (ret < 0)
>> + return ret;
>> +
>> + switch (type) {
>> + case hwmon_fan:
>> + switch (attr) {
>> + case hwmon_fan_input:
>> + if (fst.speed == FAN_SPEED_UNAVAILABLE)
>> + return -ENODATA;
>> +
>> + if (fst.speed > LONG_MAX)
>> + return -EOVERFLOW;
>> +
>> + *val = fst.speed;
>> + return 0;
>> + case hwmon_fan_target:
>> + fps = acpi_fan_get_current_fps(fan, fst.control);
>> + if (!fps)
>> + return -ENODATA;
>> +
>> + if (fps->speed > LONG_MAX)
>> + return -EOVERFLOW;
>> +
>> + *val = fps->speed;
>> + return 0;
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> + case hwmon_power:
>> + switch (attr) {
>> + case hwmon_power_input:
>> + fps = acpi_fan_get_current_fps(fan, fst.control);
>> + if (!fps)
>> + return -ENODATA;
>> +
>> + 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;
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> +}
>> +
>> +static const struct hwmon_ops acpi_fan_ops = {
>> + .is_visible = acpi_fan_is_visible,
>> + .read = acpi_fan_read,
>> +};
>
> I would add "hwmon" to the names of functions and variables related to
> hwmon. Something like
>
> +static const struct hwmon_ops acpi_fan_hwmon_ops = {
> + .is_visible = acpi_fan_hwmon_is_visible,
> + .read = acpi_fan_hwmon_read,
> +};
>
> Otherwise, it looks fine to me.
>
>> +
>> +static const struct hwmon_channel_info * const acpi_fan_info[] = {
>> + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_TARGET),
>> + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT),
>> + NULL
>> +};
>> +
>> +static const struct hwmon_chip_info acpi_fan_chip_info = {
>> + .ops = &acpi_fan_ops,
>> + .info = acpi_fan_info,
>> +};
>> +
>> +int devm_acpi_fan_create_hwmon(struct acpi_device *device)
>> +{
>> + struct acpi_fan *fan = acpi_driver_data(device);
>> + struct device *hdev;
>> +
>> + hdev = devm_hwmon_device_register_with_info(&device->dev, "acpi_fan", fan,
>> + &acpi_fan_chip_info, NULL);
>> + return PTR_ERR_OR_ZERO(hdev);
>> +}
>> --
Am 24.04.24 um 21:42 schrieb Guenter Roeck:
> On 4/24/24 12:01, Rafael J. Wysocki wrote:
>> On Mon, Apr 22, 2024 at 9:58 PM Armin Wolf <[email protected]> wrote:
>>>
>>> Currently, the driver does only support a custom sysfs
>>> interface to allow userspace to read the fan speed.
>>> Add support for the standard hwmon interface so users
>>> can read the fan speed with standard tools like "sensors".
>>>
>>> Tested with a custom ACPI SSDT.
>>>
>>> Signed-off-by: Armin Wolf <[email protected]>
>>
>> I need Guenter to tell me that this is fine with him.
>>
>
> Sorry, I have no idea. Se below.
>
>> Also please see one nit below.
>>
>>> ---
>>> Changes since v5:
>>> - fix coding style issues
>>> - replace double break with return
>>> - add missing includes
>>>
>>> Changes since v4:
>>> - fix spelling issues
>>> - check power values for overflow condition too
>>>
>>> Changes since v3:
>>> - drop fault attrs
>>> - rework initialization
>>>
>>> Changes since v2:
>>> - add support for fanX_target and power attrs
>>>
>>> Changes since v1:
>>> - fix undefined reference error
>>> - fix fan speed validation
>>> - coding style fixes
>>> - clarify that the changes are compile-tested only
>>> - add hwmon maintainers to cc list
>>> ---
>>> drivers/acpi/Makefile | 1 +
>>> drivers/acpi/fan.h | 9 +++
>>> drivers/acpi/fan_core.c | 4 +
>>> drivers/acpi/fan_hwmon.c | 169
>>> +++++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 183 insertions(+)
>>> create mode 100644 drivers/acpi/fan_hwmon.c
>>>
>>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>>> index 39ea5cfa8326..61ca4afe83dc 100644
>>> --- a/drivers/acpi/Makefile
>>> +++ b/drivers/acpi/Makefile
>>> @@ -77,6 +77,7 @@ obj-$(CONFIG_ACPI_TINY_POWER_BUTTON) +=
>>> tiny-power-button.o
>>> obj-$(CONFIG_ACPI_FAN) += fan.o
>>> fan-objs := fan_core.o
>>> fan-objs += fan_attr.o
>>> +fan-$(CONFIG_HWMON) += fan_hwmon.o
>>>
>>> obj-$(CONFIG_ACPI_VIDEO) += video.o
>>> obj-$(CONFIG_ACPI_TAD) += acpi_tad.o
>>> diff --git a/drivers/acpi/fan.h b/drivers/acpi/fan.h
>>> index f89d19c922dc..db25a3898af7 100644
>>> --- a/drivers/acpi/fan.h
>>> +++ b/drivers/acpi/fan.h
>>> @@ -10,6 +10,8 @@
>>> #ifndef _ACPI_FAN_H_
>>> #define _ACPI_FAN_H_
>>>
>>> +#include <linux/kconfig.h>
>>> +
>>> #define ACPI_FAN_DEVICE_IDS \
>>> {"INT3404", }, /* Fan */ \
>>> {"INTC1044", }, /* Fan for Tiger Lake generation */ \
>>> @@ -57,4 +59,11 @@ struct acpi_fan {
>>> int acpi_fan_get_fst(struct acpi_device *device, struct
>>> acpi_fan_fst *fst);
>>> int acpi_fan_create_attributes(struct acpi_device *device);
>>> void acpi_fan_delete_attributes(struct acpi_device *device);
>>> +
>>> +#if IS_REACHABLE(CONFIG_HWMON)
>>> +int devm_acpi_fan_create_hwmon(struct acpi_device *device);
>>> +#else
>>> +static inline int devm_acpi_fan_create_hwmon(struct acpi_device
>>> *device) { return 0; };
>>> +#endif
>>> +
>>> #endif
>>> diff --git a/drivers/acpi/fan_core.c b/drivers/acpi/fan_core.c
>>> index ff72e4ef8738..7cea4495f19b 100644
>>> --- a/drivers/acpi/fan_core.c
>>> +++ b/drivers/acpi/fan_core.c
>>> @@ -336,6 +336,10 @@ static int acpi_fan_probe(struct
>>> platform_device *pdev)
>>> if (result)
>>> return result;
>>>
>>> + result = devm_acpi_fan_create_hwmon(device);
>>> + if (result)
>>> + return result;
>>> +
>>> result = acpi_fan_create_attributes(device);
>>> if (result)
>>> return result;
>>> diff --git a/drivers/acpi/fan_hwmon.c b/drivers/acpi/fan_hwmon.c
>>> new file mode 100644
>>> index 000000000000..34a524c285a5
>>> --- /dev/null
>>> +++ b/drivers/acpi/fan_hwmon.c
>>> @@ -0,0 +1,169 @@
>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>> +/*
>>> + * Hwmon interface for the ACPI Fan driver.
>>> + *
>>> + * Copyright (C) 2024 Armin Wolf <[email protected]>
>>> + */
>>> +
>>> +#include <linux/acpi.h>
>>> +#include <linux/device.h>
>>> +#include <linux/err.h>
>>> +#include <linux/hwmon.h>
>>> +#include <linux/limits.h>
>>> +#include <linux/units.h>
>>> +
>>> +#include "fan.h"
>>> +
>>> +/* Returned when the ACPI fan does not support speed reporting */
>>> +#define FAN_SPEED_UNAVAILABLE U32_MAX
>>> +#define FAN_POWER_UNAVAILABLE U32_MAX
>>> +
>>> +static struct acpi_fan_fps *acpi_fan_get_current_fps(struct
>>> acpi_fan *fan, u64 control)
>>> +{
>>> + unsigned int i;
>>> +
>>> + for (i = 0; i < fan->fps_count; i++) {
>>> + if (fan->fps[i].control == control)
>>> + return &fan->fps[i];
>>> + }
>>> +
>>> + return NULL;
>>> +}
>>> +
>>> +static umode_t acpi_fan_is_visible(const void *drvdata, enum
>>> hwmon_sensor_types type, u32 attr,
>>> + int channel)
>>> +{
>>> + const struct acpi_fan *fan = drvdata;
>>> + unsigned int i;
>>> +
>>> + switch (type) {
>>> + case hwmon_fan:
>>> + switch (attr) {
>>> + case hwmon_fan_input:
>>> + return 0444;
>>> + case hwmon_fan_target:
>>> + /*
>>> + * When in fine grain control mode, not
>>> every fan control value
>>> + * has an associated fan performance state.
>>> + */
>>> + if (fan->fif.fine_grain_ctrl)
>>> + return 0;
>>> +
>>> + return 0444;
>>> + default:
>>> + return 0;
>>> + }
>>> + case hwmon_power:
>>> + switch (attr) {
>>> + case hwmon_power_input:
>>> + /*
>>> + * When in fine grain control mode, not
>>> every fan control value
>>> + * has an associated fan performance state.
>>> + */
>>> + if (fan->fif.fine_grain_ctrl)
>>> + return 0;
>>> +
>>> + /*
>>> + * When all fan performance states contain
>>> no valid power data,
>>> + * when the associated attribute should not
>>> be created.
>>> + */
>>> + for (i = 0; i < fan->fps_count; i++) {
>>> + if (fan->fps[i].power !=
>>> FAN_POWER_UNAVAILABLE)
>>> + return 0444;
>>> + }
>
> Is this all or nothing ? Doesn't this depend on the channel ? It looks
> as if the first fan supports reporting the power, attributes are
> generated for all fans even if the others don't support it
Hi,
those fps entries are different performance states for a single fan, see ACPI spec 11.3.1.2
(link: https://uefi.org/specs/ACPI/6.5/11_Thermal_Management.html#fan-device).
The code basically checks that if at least one performance state contains valid power data,
the powerX_input attribute is created.
>
> To me it looks like there are situations where individual
> fans will still persistently report -ENODATA for fan speed, power,
> or both. I don't know the specification well enough (not at all, really)
> to be able to determine if this makes sense. Normally, -ENODATA should be
> reserved for "value temporarily not available". I am not sure if that is
> the case here.
>
> Guenter
>
The power attributes will not be created if all performance states contain no valid
power values, so -ENODATA will only be returned if the current performance state contains
no valid power data (unlikely to happen, all firmware implementations i have seen either
contain valid power values for all performance states or none at all).
The fan attributes are a bit different, as FAN_SPEED_UNAVAILABLE can either signal that
fan speed reporting is not supported _or_ that reading of the fan speed failed, so we cannot
check if FAN_SPEED_UNAVAILABLE was returned due to a temporary error or due to missing support.
Thanks,
Armin Wolf
>>> +
>>> + return 0;
>>> + default:
>>> + return 0;
>>> + }
>>> + default:
>>> + return 0;
>>> + }
>>> +}
>>> +
>>> +static int acpi_fan_read(struct device *dev, enum
>>> hwmon_sensor_types type, u32 attr, int channel,
>>> + long *val)
>>> +{
>>> + struct acpi_device *adev = to_acpi_device(dev->parent);
>>> + struct acpi_fan *fan = dev_get_drvdata(dev);
>>> + struct acpi_fan_fps *fps;
>>> + struct acpi_fan_fst fst;
>>> + int ret;
>>> +
>>> + ret = acpi_fan_get_fst(adev, &fst);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + switch (type) {
>>> + case hwmon_fan:
>>> + switch (attr) {
>>> + case hwmon_fan_input:
>>> + if (fst.speed == FAN_SPEED_UNAVAILABLE)
>>> + return -ENODATA;
>>> +
>>> + if (fst.speed > LONG_MAX)
>>> + return -EOVERFLOW;
>>> +
>>> + *val = fst.speed;
>>> + return 0;
>>> + case hwmon_fan_target:
>>> + fps = acpi_fan_get_current_fps(fan,
>>> fst.control);
>>> + if (!fps)
>>> + return -ENODATA;
>>> +
>>> + if (fps->speed > LONG_MAX)
>>> + return -EOVERFLOW;
>>> +
>>> + *val = fps->speed;
>>> + return 0;
>>> + default:
>>> + return -EOPNOTSUPP;
>>> + }
>>> + case hwmon_power:
>>> + switch (attr) {
>>> + case hwmon_power_input:
>>> + fps = acpi_fan_get_current_fps(fan,
>>> fst.control);
>>> + if (!fps)
>>> + return -ENODATA;
>>> +
>>> + 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;
>>> + default:
>>> + return -EOPNOTSUPP;
>>> + }
>>> + default:
>>> + return -EOPNOTSUPP;
>>> + }
>>> +}
>>> +
>>> +static const struct hwmon_ops acpi_fan_ops = {
>>> + .is_visible = acpi_fan_is_visible,
>>> + .read = acpi_fan_read,
>>> +};
>>
>> I would add "hwmon" to the names of functions and variables related to
>> hwmon. Something like
>>
>> +static const struct hwmon_ops acpi_fan_hwmon_ops = {
>> + .is_visible = acpi_fan_hwmon_is_visible,
>> + .read = acpi_fan_hwmon_read,
>> +};
>>
>> Otherwise, it looks fine to me.
>>
>>> +
>>> +static const struct hwmon_channel_info * const acpi_fan_info[] = {
>>> + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_TARGET),
>>> + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT),
>>> + NULL
>>> +};
>>> +
>>> +static const struct hwmon_chip_info acpi_fan_chip_info = {
>>> + .ops = &acpi_fan_ops,
>>> + .info = acpi_fan_info,
>>> +};
>>> +
>>> +int devm_acpi_fan_create_hwmon(struct acpi_device *device)
>>> +{
>>> + struct acpi_fan *fan = acpi_driver_data(device);
>>> + struct device *hdev;
>>> +
>>> + hdev = devm_hwmon_device_register_with_info(&device->dev,
>>> "acpi_fan", fan,
>>> + &acpi_fan_chip_info, NULL);
>>> + return PTR_ERR_OR_ZERO(hdev);
>>> +}
>>> --
>
Am 24.04.24 um 23:53 schrieb Armin Wolf:
> Am 24.04.24 um 21:42 schrieb Guenter Roeck:
>
>> On 4/24/24 12:01, Rafael J. Wysocki wrote:
>>> On Mon, Apr 22, 2024 at 9:58 PM Armin Wolf <[email protected]> wrote:
>>>>
>>>> Currently, the driver does only support a custom sysfs
>>>> interface to allow userspace to read the fan speed.
>>>> Add support for the standard hwmon interface so users
>>>> can read the fan speed with standard tools like "sensors".
>>>>
>>>> Tested with a custom ACPI SSDT.
>>>>
>>>> Signed-off-by: Armin Wolf <[email protected]>
>>>
>>> I need Guenter to tell me that this is fine with him.
>>>
>>
>> Sorry, I have no idea. Se below.
>>
>>> Also please see one nit below.
>>>
>>>> ---
>>>> Changes since v5:
>>>> - fix coding style issues
>>>> - replace double break with return
>>>> - add missing includes
>>>>
>>>> Changes since v4:
>>>> - fix spelling issues
>>>> - check power values for overflow condition too
>>>>
>>>> Changes since v3:
>>>> - drop fault attrs
>>>> - rework initialization
>>>>
>>>> Changes since v2:
>>>> - add support for fanX_target and power attrs
>>>>
>>>> Changes since v1:
>>>> - fix undefined reference error
>>>> - fix fan speed validation
>>>> - coding style fixes
>>>> - clarify that the changes are compile-tested only
>>>> - add hwmon maintainers to cc list
>>>> ---
>>>> drivers/acpi/Makefile | 1 +
>>>> drivers/acpi/fan.h | 9 +++
>>>> drivers/acpi/fan_core.c | 4 +
>>>> drivers/acpi/fan_hwmon.c | 169
>>>> +++++++++++++++++++++++++++++++++++++++
>>>> 4 files changed, 183 insertions(+)
>>>> create mode 100644 drivers/acpi/fan_hwmon.c
>>>>
>>>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>>>> index 39ea5cfa8326..61ca4afe83dc 100644
>>>> --- a/drivers/acpi/Makefile
>>>> +++ b/drivers/acpi/Makefile
>>>> @@ -77,6 +77,7 @@ obj-$(CONFIG_ACPI_TINY_POWER_BUTTON) +=
>>>> tiny-power-button.o
>>>> obj-$(CONFIG_ACPI_FAN) += fan.o
>>>> fan-objs := fan_core.o
>>>> fan-objs += fan_attr.o
>>>> +fan-$(CONFIG_HWMON) += fan_hwmon.o
>>>>
>>>> obj-$(CONFIG_ACPI_VIDEO) += video.o
>>>> obj-$(CONFIG_ACPI_TAD) += acpi_tad.o
>>>> diff --git a/drivers/acpi/fan.h b/drivers/acpi/fan.h
>>>> index f89d19c922dc..db25a3898af7 100644
>>>> --- a/drivers/acpi/fan.h
>>>> +++ b/drivers/acpi/fan.h
>>>> @@ -10,6 +10,8 @@
>>>> #ifndef _ACPI_FAN_H_
>>>> #define _ACPI_FAN_H_
>>>>
>>>> +#include <linux/kconfig.h>
>>>> +
>>>> #define ACPI_FAN_DEVICE_IDS \
>>>> {"INT3404", }, /* Fan */ \
>>>> {"INTC1044", }, /* Fan for Tiger Lake generation */ \
>>>> @@ -57,4 +59,11 @@ struct acpi_fan {
>>>> int acpi_fan_get_fst(struct acpi_device *device, struct
>>>> acpi_fan_fst *fst);
>>>> int acpi_fan_create_attributes(struct acpi_device *device);
>>>> void acpi_fan_delete_attributes(struct acpi_device *device);
>>>> +
>>>> +#if IS_REACHABLE(CONFIG_HWMON)
>>>> +int devm_acpi_fan_create_hwmon(struct acpi_device *device);
>>>> +#else
>>>> +static inline int devm_acpi_fan_create_hwmon(struct acpi_device
>>>> *device) { return 0; };
>>>> +#endif
>>>> +
>>>> #endif
>>>> diff --git a/drivers/acpi/fan_core.c b/drivers/acpi/fan_core.c
>>>> index ff72e4ef8738..7cea4495f19b 100644
>>>> --- a/drivers/acpi/fan_core.c
>>>> +++ b/drivers/acpi/fan_core.c
>>>> @@ -336,6 +336,10 @@ static int acpi_fan_probe(struct
>>>> platform_device *pdev)
>>>> if (result)
>>>> return result;
>>>>
>>>> + result = devm_acpi_fan_create_hwmon(device);
>>>> + if (result)
>>>> + return result;
>>>> +
>>>> result = acpi_fan_create_attributes(device);
>>>> if (result)
>>>> return result;
>>>> diff --git a/drivers/acpi/fan_hwmon.c b/drivers/acpi/fan_hwmon.c
>>>> new file mode 100644
>>>> index 000000000000..34a524c285a5
>>>> --- /dev/null
>>>> +++ b/drivers/acpi/fan_hwmon.c
>>>> @@ -0,0 +1,169 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>>> +/*
>>>> + * Hwmon interface for the ACPI Fan driver.
>>>> + *
>>>> + * Copyright (C) 2024 Armin Wolf <[email protected]>
>>>> + */
>>>> +
>>>> +#include <linux/acpi.h>
>>>> +#include <linux/device.h>
>>>> +#include <linux/err.h>
>>>> +#include <linux/hwmon.h>
>>>> +#include <linux/limits.h>
>>>> +#include <linux/units.h>
>>>> +
>>>> +#include "fan.h"
>>>> +
>>>> +/* Returned when the ACPI fan does not support speed reporting */
>>>> +#define FAN_SPEED_UNAVAILABLE U32_MAX
>>>> +#define FAN_POWER_UNAVAILABLE U32_MAX
>>>> +
>>>> +static struct acpi_fan_fps *acpi_fan_get_current_fps(struct
>>>> acpi_fan *fan, u64 control)
>>>> +{
>>>> + unsigned int i;
>>>> +
>>>> + for (i = 0; i < fan->fps_count; i++) {
>>>> + if (fan->fps[i].control == control)
>>>> + return &fan->fps[i];
>>>> + }
>>>> +
>>>> + return NULL;
>>>> +}
>>>> +
>>>> +static umode_t acpi_fan_is_visible(const void *drvdata, enum
>>>> hwmon_sensor_types type, u32 attr,
>>>> + int channel)
>>>> +{
>>>> + const struct acpi_fan *fan = drvdata;
>>>> + unsigned int i;
>>>> +
>>>> + switch (type) {
>>>> + case hwmon_fan:
>>>> + switch (attr) {
>>>> + case hwmon_fan_input:
>>>> + return 0444;
>>>> + case hwmon_fan_target:
>>>> + /*
>>>> + * When in fine grain control mode, not
>>>> every fan control value
>>>> + * has an associated fan performance state.
>>>> + */
>>>> + if (fan->fif.fine_grain_ctrl)
>>>> + return 0;
>>>> +
>>>> + return 0444;
>>>> + default:
>>>> + return 0;
>>>> + }
>>>> + case hwmon_power:
>>>> + switch (attr) {
>>>> + case hwmon_power_input:
>>>> + /*
>>>> + * When in fine grain control mode, not
>>>> every fan control value
>>>> + * has an associated fan performance state.
>>>> + */
>>>> + if (fan->fif.fine_grain_ctrl)
>>>> + return 0;
>>>> +
>>>> + /*
>>>> + * When all fan performance states contain
>>>> no valid power data,
>>>> + * when the associated attribute should not
>>>> be created.
>>>> + */
>>>> + for (i = 0; i < fan->fps_count; i++) {
>>>> + if (fan->fps[i].power !=
>>>> FAN_POWER_UNAVAILABLE)
>>>> + return 0444;
>>>> + }
>>
>> Is this all or nothing ? Doesn't this depend on the channel ? It looks
>> as if the first fan supports reporting the power, attributes are
>> generated for all fans even if the others don't support it
>
> Hi,
>
> those fps entries are different performance states for a single fan,
> see ACPI spec 11.3.1.2
> (link:
> https://uefi.org/specs/ACPI/6.5/11_Thermal_Management.html#fan-device).
>
> The code basically checks that if at least one performance state
> contains valid power data,
> the powerX_input attribute is created.
>
>>
>> To me it looks like there are situations where individual
>> fans will still persistently report -ENODATA for fan speed, power,
>> or both. I don't know the specification well enough (not at all, really)
>> to be able to determine if this makes sense. Normally, -ENODATA
>> should be
>> reserved for "value temporarily not available". I am not sure if that is
>> the case here.
>>
>> Guenter
>>
> The power attributes will not be created if all performance states
> contain no valid
> power values, so -ENODATA will only be returned if the current
> performance state contains
> no valid power data (unlikely to happen, all firmware implementations
> i have seen either
> contain valid power values for all performance states or none at all).
>
> The fan attributes are a bit different, as FAN_SPEED_UNAVAILABLE can
> either signal that
> fan speed reporting is not supported _or_ that reading of the fan
> speed failed, so we cannot
> check if FAN_SPEED_UNAVAILABLE was returned due to a temporary error
> or due to missing support.
>
> Thanks,
> Armin Wolf
Any progress with this?
I can try to explain the ACPI FAN specification a bit more if necessary.
Thanks,
Armin Wolf
>
>>>> +
>>>> + return 0;
>>>> + default:
>>>> + return 0;
>>>> + }
>>>> + default:
>>>> + return 0;
>>>> + }
>>>> +}
>>>> +
>>>> +static int acpi_fan_read(struct device *dev, enum
>>>> hwmon_sensor_types type, u32 attr, int channel,
>>>> + long *val)
>>>> +{
>>>> + struct acpi_device *adev = to_acpi_device(dev->parent);
>>>> + struct acpi_fan *fan = dev_get_drvdata(dev);
>>>> + struct acpi_fan_fps *fps;
>>>> + struct acpi_fan_fst fst;
>>>> + int ret;
>>>> +
>>>> + ret = acpi_fan_get_fst(adev, &fst);
>>>> + if (ret < 0)
>>>> + return ret;
>>>> +
>>>> + switch (type) {
>>>> + case hwmon_fan:
>>>> + switch (attr) {
>>>> + case hwmon_fan_input:
>>>> + if (fst.speed == FAN_SPEED_UNAVAILABLE)
>>>> + return -ENODATA;
>>>> +
>>>> + if (fst.speed > LONG_MAX)
>>>> + return -EOVERFLOW;
>>>> +
>>>> + *val = fst.speed;
>>>> + return 0;
>>>> + case hwmon_fan_target:
>>>> + fps = acpi_fan_get_current_fps(fan,
>>>> fst.control);
>>>> + if (!fps)
>>>> + return -ENODATA;
>>>> +
>>>> + if (fps->speed > LONG_MAX)
>>>> + return -EOVERFLOW;
>>>> +
>>>> + *val = fps->speed;
>>>> + return 0;
>>>> + default:
>>>> + return -EOPNOTSUPP;
>>>> + }
>>>> + case hwmon_power:
>>>> + switch (attr) {
>>>> + case hwmon_power_input:
>>>> + fps = acpi_fan_get_current_fps(fan,
>>>> fst.control);
>>>> + if (!fps)
>>>> + return -ENODATA;
>>>> +
>>>> + 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;
>>>> + default:
>>>> + return -EOPNOTSUPP;
>>>> + }
>>>> + default:
>>>> + return -EOPNOTSUPP;
>>>> + }
>>>> +}
>>>> +
>>>> +static const struct hwmon_ops acpi_fan_ops = {
>>>> + .is_visible = acpi_fan_is_visible,
>>>> + .read = acpi_fan_read,
>>>> +};
>>>
>>> I would add "hwmon" to the names of functions and variables related to
>>> hwmon. Something like
>>>
>>> +static const struct hwmon_ops acpi_fan_hwmon_ops = {
>>> + .is_visible = acpi_fan_hwmon_is_visible,
>>> + .read = acpi_fan_hwmon_read,
>>> +};
>>>
>>> Otherwise, it looks fine to me.
>>>
>>>> +
>>>> +static const struct hwmon_channel_info * const acpi_fan_info[] = {
>>>> + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_TARGET),
>>>> + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT),
>>>> + NULL
>>>> +};
>>>> +
>>>> +static const struct hwmon_chip_info acpi_fan_chip_info = {
>>>> + .ops = &acpi_fan_ops,
>>>> + .info = acpi_fan_info,
>>>> +};
>>>> +
>>>> +int devm_acpi_fan_create_hwmon(struct acpi_device *device)
>>>> +{
>>>> + struct acpi_fan *fan = acpi_driver_data(device);
>>>> + struct device *hdev;
>>>> +
>>>> + hdev = devm_hwmon_device_register_with_info(&device->dev,
>>>> "acpi_fan", fan,
>>>> + &acpi_fan_chip_info, NULL);
>>>> + return PTR_ERR_OR_ZERO(hdev);
>>>> +}
>>>> --
>>
On Sun, May 05, 2024 at 07:22:25PM +0200, Armin Wolf wrote:
>
> Any progress with this?
>
Not really. It all seems odd, and I returning -ENODATA doesn't seem right,
but then I don't understand the specification or the logic behind it, and
I don't have the time to read and understand it. No objection from my side
against moving forward.
Guenter