Re: [PATCH v6] ACPI: fan: Add hwmon support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/24/24 12:01, Rafael J. Wysocki wrote:
On Mon, Apr 22, 2024 at 9:58 PM Armin Wolf <W_Armin@xxxxxx> 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 <W_Armin@xxxxxx>

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 <W_Armin@xxxxxx>
+ */
+
+#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);
+}
--





[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux