lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 May 2024 19:22:25 +0200
From: Armin Wolf <W_Armin@....de>
To: Guenter Roeck <linux@...ck-us.net>, "Rafael J. Wysocki"
 <rafael@...nel.org>
Cc: mlj@...elec.com, rafael.j.wysocki@...el.com, lenb@...nel.org,
 jdelvare@...e.com, andy.shevchenko@...il.com, linux@...ssschuh.net,
 ilpo.jarvinen@...ux.intel.com, linux-acpi@...r.kernel.org,
 linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
 platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v6] ACPI: fan: Add hwmon support

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ