* [PATCH v3 1/2] hwmon: (core) Add support for power fault attribute @ 2024-04-12 16:08 Armin Wolf 2024-04-12 16:08 ` [PATCH v3 2/2] ACPI: fan: Add hwmon support Armin Wolf 0 siblings, 1 reply; 6+ messages in thread From: Armin Wolf @ 2024-04-12 16:08 UTC (permalink / raw) To: mlj, rafael.j.wysocki, lenb Cc: jdelvare, linux, linux, ilpo.jarvinen, linux-acpi, linux-hwmon, linux-kernel, platform-driver-x86 Power sensor driver might want to signal that the power value is not usable. Add a new power fault attribute to report such failures. Signed-off-by: Armin Wolf <W_Armin@gmx.de> --- Changes since v2: - added patch --- Documentation/ABI/testing/sysfs-class-hwmon | 9 +++++++++ drivers/hwmon/hwmon.c | 1 + include/linux/hwmon.h | 2 ++ 3 files changed, 12 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon index cfd0d0bab483..ed01d43d2491 100644 --- a/Documentation/ABI/testing/sysfs-class-hwmon +++ b/Documentation/ABI/testing/sysfs-class-hwmon @@ -882,6 +882,15 @@ Description: RW +What: /sys/class/hwmon/hwmonX/powerY_fault +Description: + Reports a power sensor failure. + + - 1: Failed + - 0: Ok + + RO + What: /sys/class/hwmon/hwmonX/powerY_rated_min Description: Minimum rated power. diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c index 3b259c425ab7..6150d64f5c4c 100644 --- a/drivers/hwmon/hwmon.c +++ b/drivers/hwmon/hwmon.c @@ -560,6 +560,7 @@ static const char * const hwmon_power_attr_templates[] = { [hwmon_power_crit] = "power%d_crit", [hwmon_power_label] = "power%d_label", [hwmon_power_alarm] = "power%d_alarm", + [hwmon_power_fault] = "power%d_fault", [hwmon_power_cap_alarm] = "power%d_cap_alarm", [hwmon_power_min_alarm] = "power%d_min_alarm", [hwmon_power_max_alarm] = "power%d_max_alarm", diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h index edf96f249eb5..00122e565dbf 100644 --- a/include/linux/hwmon.h +++ b/include/linux/hwmon.h @@ -237,6 +237,7 @@ enum hwmon_power_attributes { hwmon_power_max_alarm, hwmon_power_lcrit_alarm, hwmon_power_crit_alarm, + hwmon_power_fault, hwmon_power_rated_min, hwmon_power_rated_max, }; @@ -270,6 +271,7 @@ enum hwmon_power_attributes { #define HWMON_P_MAX_ALARM BIT(hwmon_power_max_alarm) #define HWMON_P_LCRIT_ALARM BIT(hwmon_power_lcrit_alarm) #define HWMON_P_CRIT_ALARM BIT(hwmon_power_crit_alarm) +#define HWMON_P_FAULT BIT(hwmon_power_fault) #define HWMON_P_RATED_MIN BIT(hwmon_power_rated_min) #define HWMON_P_RATED_MAX BIT(hwmon_power_rated_max) -- 2.39.2 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v3 2/2] ACPI: fan: Add hwmon support 2024-04-12 16:08 [PATCH v3 1/2] hwmon: (core) Add support for power fault attribute Armin Wolf @ 2024-04-12 16:08 ` Armin Wolf 2024-04-12 16:41 ` Guenter Roeck 0 siblings, 1 reply; 6+ messages in thread From: Armin Wolf @ 2024-04-12 16:08 UTC (permalink / raw) To: mlj, rafael.j.wysocki, lenb Cc: jdelvare, linux, linux, ilpo.jarvinen, linux-acpi, linux-hwmon, linux-kernel, platform-driver-x86 Currently, the driver does only support a custom sysfs 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". Compile-tested only. Signed-off-by: Armin Wolf <W_Armin@gmx.de> --- 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 The changes will be tested by Mikael Lund Jepsen from Danelec and should be merged only after those tests. --- drivers/acpi/Makefile | 1 + drivers/acpi/fan.h | 9 +++ drivers/acpi/fan_core.c | 4 ++ drivers/acpi/fan_hwmon.c | 148 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 162 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..57216ba872db --- /dev/null +++ b/drivers/acpi/fan_hwmon.c @@ -0,0 +1,148 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * fan_hwmon.c - hwmon interface for the ACPI Fan driver + * + * Copyright (C) 2024 Armin Wolf <W_Armin@gmx.de> + */ + +#include <linux/acpi.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 0xffffffff +#define FAN_POWER_UNAVAILABLE 0xffffffff + +static struct acpi_fan_fps *acpi_fan_get_current_fps(struct acpi_fan *fan, u64 control) +{ + 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) +{ + return 0444; +} + +static int acpi_fan_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel, + long *val) +{ + struct acpi_device *adev = dev_get_drvdata(dev); + struct acpi_fan *fan = acpi_driver_data(adev); + 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; + + *val = fps->speed; + return 0; + case hwmon_fan_fault: + *val = (fst.speed == FAN_SPEED_UNAVAILABLE); + return 0; + 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); + return 0; + default: + break; + } + break; + default: + break; + } + + 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_F_FAULT), + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT | HWMON_P_FAULT), + NULL +}; + +static const struct hwmon_chip_info acpi_fan_chip_info = { + .ops = &acpi_fan_ops, + .info = acpi_fan_info, +}; + +static const struct hwmon_channel_info * const acpi_fan_fine_grain_info[] = { + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_FAULT), + NULL +}; + +static const struct hwmon_chip_info acpi_fan_fine_grain_chip_info = { + .ops = &acpi_fan_ops, + .info = acpi_fan_fine_grain_info, +}; + +int devm_acpi_fan_create_hwmon(struct acpi_device *device) +{ + struct acpi_fan *fan = acpi_driver_data(device); + const struct hwmon_chip_info *info; + struct device *hdev; + + /* When in fine grain control mode, not every fan control value + * has an associated fan performance state. + */ + if (fan->fif.fine_grain_ctrl) + info = &acpi_fan_fine_grain_chip_info; + else + info = &acpi_fan_chip_info; + + hdev = devm_hwmon_device_register_with_info(&device->dev, "acpi_fan", device, info, NULL); + + return PTR_ERR_OR_ZERO(hdev); +} -- 2.39.2 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 2/2] ACPI: fan: Add hwmon support 2024-04-12 16:08 ` [PATCH v3 2/2] ACPI: fan: Add hwmon support Armin Wolf @ 2024-04-12 16:41 ` Guenter Roeck 2024-04-12 20:27 ` Armin Wolf 0 siblings, 1 reply; 6+ messages in thread From: Guenter Roeck @ 2024-04-12 16:41 UTC (permalink / raw) To: Armin Wolf Cc: mlj, rafael.j.wysocki, lenb, jdelvare, linux, ilpo.jarvinen, linux-acpi, linux-hwmon, linux-kernel, platform-driver-x86 On Fri, Apr 12, 2024 at 06:08:57PM +0200, Armin Wolf wrote: > Currently, the driver does only support a custom sysfs > 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". > > Compile-tested only. > > Signed-off-by: Armin Wolf <W_Armin@gmx.de> > --- > 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 > > The changes will be tested by Mikael Lund Jepsen from Danelec and > should be merged only after those tests. > --- > drivers/acpi/Makefile | 1 + > drivers/acpi/fan.h | 9 +++ > drivers/acpi/fan_core.c | 4 ++ > drivers/acpi/fan_hwmon.c | 148 +++++++++++++++++++++++++++++++++++++++ > 4 files changed, 162 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..57216ba872db > --- /dev/null > +++ b/drivers/acpi/fan_hwmon.c > @@ -0,0 +1,148 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * fan_hwmon.c - hwmon interface for the ACPI Fan driver > + * > + * Copyright (C) 2024 Armin Wolf <W_Armin@gmx.de> > + */ > + > +#include <linux/acpi.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 0xffffffff > +#define FAN_POWER_UNAVAILABLE 0xffffffff > + > +static struct acpi_fan_fps *acpi_fan_get_current_fps(struct acpi_fan *fan, u64 control) > +{ > + 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) > +{ > + return 0444; > +} > + > +static int acpi_fan_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel, > + long *val) > +{ > + struct acpi_device *adev = dev_get_drvdata(dev); > + struct acpi_fan *fan = acpi_driver_data(adev); > + 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; > + > + *val = fps->speed; > + return 0; > + case hwmon_fan_fault: > + *val = (fst.speed == FAN_SPEED_UNAVAILABLE); Is it documented that this is indeed a fault (broken fan) ? > + return 0; > + 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); Is it documented that this is indeed a power supply failure ? What if the value is simply not reported ? "UNAVAILABLE" is not commonly associated with a "fault". Guenter > + return 0; > + default: > + break; > + } > + break; > + default: > + break; > + } > + > + 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_F_FAULT), > + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT | HWMON_P_FAULT), > + NULL > +}; > + > +static const struct hwmon_chip_info acpi_fan_chip_info = { > + .ops = &acpi_fan_ops, > + .info = acpi_fan_info, > +}; > + > +static const struct hwmon_channel_info * const acpi_fan_fine_grain_info[] = { > + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_FAULT), > + NULL > +}; > + > +static const struct hwmon_chip_info acpi_fan_fine_grain_chip_info = { > + .ops = &acpi_fan_ops, > + .info = acpi_fan_fine_grain_info, > +}; > + > +int devm_acpi_fan_create_hwmon(struct acpi_device *device) > +{ > + struct acpi_fan *fan = acpi_driver_data(device); > + const struct hwmon_chip_info *info; > + struct device *hdev; > + > + /* When in fine grain control mode, not every fan control value > + * has an associated fan performance state. > + */ > + if (fan->fif.fine_grain_ctrl) > + info = &acpi_fan_fine_grain_chip_info; > + else > + info = &acpi_fan_chip_info; > + > + hdev = devm_hwmon_device_register_with_info(&device->dev, "acpi_fan", device, info, NULL); > + > + return PTR_ERR_OR_ZERO(hdev); > +} > -- > 2.39.2 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 2/2] ACPI: fan: Add hwmon support 2024-04-12 16:41 ` Guenter Roeck @ 2024-04-12 20:27 ` Armin Wolf 2024-04-12 21:01 ` Guenter Roeck 0 siblings, 1 reply; 6+ messages in thread From: Armin Wolf @ 2024-04-12 20:27 UTC (permalink / raw) To: Guenter Roeck Cc: mlj, rafael.j.wysocki, lenb, jdelvare, linux, ilpo.jarvinen, linux-acpi, linux-hwmon, linux-kernel, platform-driver-x86 Am 12.04.24 um 18:41 schrieb Guenter Roeck: > On Fri, Apr 12, 2024 at 06:08:57PM +0200, Armin Wolf wrote: >> Currently, the driver does only support a custom sysfs >> 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". >> >> Compile-tested only. >> >> Signed-off-by: Armin Wolf <W_Armin@gmx.de> >> --- >> 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 >> >> The changes will be tested by Mikael Lund Jepsen from Danelec and >> should be merged only after those tests. >> --- >> drivers/acpi/Makefile | 1 + >> drivers/acpi/fan.h | 9 +++ >> drivers/acpi/fan_core.c | 4 ++ >> drivers/acpi/fan_hwmon.c | 148 +++++++++++++++++++++++++++++++++++++++ >> 4 files changed, 162 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..57216ba872db >> --- /dev/null >> +++ b/drivers/acpi/fan_hwmon.c >> @@ -0,0 +1,148 @@ >> +// SPDX-License-Identifier: GPL-2.0-or-later >> +/* >> + * fan_hwmon.c - hwmon interface for the ACPI Fan driver >> + * >> + * Copyright (C) 2024 Armin Wolf <W_Armin@gmx.de> >> + */ >> + >> +#include <linux/acpi.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 0xffffffff >> +#define FAN_POWER_UNAVAILABLE 0xffffffff >> + >> +static struct acpi_fan_fps *acpi_fan_get_current_fps(struct acpi_fan *fan, u64 control) >> +{ >> + 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) >> +{ >> + return 0444; >> +} >> + >> +static int acpi_fan_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel, >> + long *val) >> +{ >> + struct acpi_device *adev = dev_get_drvdata(dev); >> + struct acpi_fan *fan = acpi_driver_data(adev); >> + 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; >> + >> + *val = fps->speed; >> + return 0; >> + case hwmon_fan_fault: >> + *val = (fst.speed == FAN_SPEED_UNAVAILABLE); > Is it documented that this is indeed a fault (broken fan) ? > Hi, it actually means that the fan does not support speed reporting. >> + return 0; >> + 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); > Is it documented that this is indeed a power supply failure ? > What if the value is simply not reported ? "UNAVAILABLE" is not > commonly associated with a "fault". > > Guenter > FAN_POWER_UNAVAILABLE signals that the power value is not supported. Would it be more suitable to drop the fault attributes and just return -ENODATA in such a case? Thanks, Armin Wolf >> + return 0; >> + default: >> + break; >> + } >> + break; >> + default: >> + break; >> + } >> + >> + 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_F_FAULT), >> + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT | HWMON_P_FAULT), >> + NULL >> +}; >> + >> +static const struct hwmon_chip_info acpi_fan_chip_info = { >> + .ops = &acpi_fan_ops, >> + .info = acpi_fan_info, >> +}; >> + >> +static const struct hwmon_channel_info * const acpi_fan_fine_grain_info[] = { >> + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_FAULT), >> + NULL >> +}; >> + >> +static const struct hwmon_chip_info acpi_fan_fine_grain_chip_info = { >> + .ops = &acpi_fan_ops, >> + .info = acpi_fan_fine_grain_info, >> +}; >> + >> +int devm_acpi_fan_create_hwmon(struct acpi_device *device) >> +{ >> + struct acpi_fan *fan = acpi_driver_data(device); >> + const struct hwmon_chip_info *info; >> + struct device *hdev; >> + >> + /* When in fine grain control mode, not every fan control value >> + * has an associated fan performance state. >> + */ >> + if (fan->fif.fine_grain_ctrl) >> + info = &acpi_fan_fine_grain_chip_info; >> + else >> + info = &acpi_fan_chip_info; >> + >> + hdev = devm_hwmon_device_register_with_info(&device->dev, "acpi_fan", device, info, NULL); >> + >> + return PTR_ERR_OR_ZERO(hdev); >> +} >> -- >> 2.39.2 >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 2/2] ACPI: fan: Add hwmon support 2024-04-12 20:27 ` Armin Wolf @ 2024-04-12 21:01 ` Guenter Roeck 2024-04-12 23:18 ` Armin Wolf 0 siblings, 1 reply; 6+ messages in thread From: Guenter Roeck @ 2024-04-12 21:01 UTC (permalink / raw) To: Armin Wolf Cc: mlj, rafael.j.wysocki, lenb, jdelvare, linux, ilpo.jarvinen, linux-acpi, linux-hwmon, linux-kernel, platform-driver-x86 On Fri, Apr 12, 2024 at 10:27:56PM +0200, Armin Wolf wrote: > > > + case hwmon_fan_fault: > > > + *val = (fst.speed == FAN_SPEED_UNAVAILABLE); > > Is it documented that this is indeed a fault (broken fan) ? > > > Hi, > > it actually means that the fan does not support speed reporting. > > > > + return 0; > > > + 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); > > Is it documented that this is indeed a power supply failure ? > > What if the value is simply not reported ? "UNAVAILABLE" is not > > commonly associated with a "fault". > > > > Guenter > > > FAN_POWER_UNAVAILABLE signals that the power value is not supported. > Would it be more suitable to drop the fault attributes and just return -ENODATA in such a case? > There should be no fault attributes unless a real fault 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 2/2] ACPI: fan: Add hwmon support 2024-04-12 21:01 ` Guenter Roeck @ 2024-04-12 23:18 ` Armin Wolf 0 siblings, 0 replies; 6+ messages in thread From: Armin Wolf @ 2024-04-12 23:18 UTC (permalink / raw) To: Guenter Roeck Cc: mlj, rafael.j.wysocki, lenb, jdelvare, linux, ilpo.jarvinen, linux-acpi, linux-hwmon, linux-kernel, platform-driver-x86 Am 12.04.24 um 23:01 schrieb Guenter Roeck: > On Fri, Apr 12, 2024 at 10:27:56PM +0200, Armin Wolf wrote: >>>> + case hwmon_fan_fault: >>>> + *val = (fst.speed == FAN_SPEED_UNAVAILABLE); >>> Is it documented that this is indeed a fault (broken fan) ? >>> >> Hi, >> >> it actually means that the fan does not support speed reporting. >> >>>> + return 0; >>>> + 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); >>> Is it documented that this is indeed a power supply failure ? >>> What if the value is simply not reported ? "UNAVAILABLE" is not >>> commonly associated with a "fault". >>> >>> Guenter >>> >> FAN_POWER_UNAVAILABLE signals that the power value is not supported. >> Would it be more suitable to drop the fault attributes and just return -ENODATA in such a case? >> > There should be no fault attributes unless a real fault > 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 > I see, however it seems that some ACPI implementations also return a fan speed of 0xffffffff to signal an error, so we cannot use this value to check if the BIOS supports fan speed reporting. I will send a v4 patch witch will drop the fault attributes. When encountering a fan speed of 0xffffffff, returning -ENODATA should be ok i think. Thanks, Armin Wolf ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-12 23:19 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-12 16:08 [PATCH v3 1/2] hwmon: (core) Add support for power fault attribute Armin Wolf 2024-04-12 16:08 ` [PATCH v3 2/2] ACPI: fan: Add hwmon support Armin Wolf 2024-04-12 16:41 ` Guenter Roeck 2024-04-12 20:27 ` Armin Wolf 2024-04-12 21:01 ` Guenter Roeck 2024-04-12 23:18 ` Armin Wolf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®