mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: mlj@danelec.com, rafael.j.wysocki@intel.com, lenb@kernel.org,
	jdelvare@suse.com, linux@weissschuh.net,
	ilpo.jarvinen@linux.intel.com, linux-acpi@vger.kernel.org,
	linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH v3 2/2] ACPI: fan: Add hwmon support
Date: Fri, 12 Apr 2024 22:27:56 +0200	[thread overview]
Message-ID: <aace96e3-8645-469b-9056-0199af9d220c@gmx.de> (raw)
In-Reply-To: <4a07f4d1-bbee-445c-a7cc-377506de850d@roeck-us.net>

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
>>

  reply	other threads:[~2024-04-12 20:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2024-04-12 21:01       ` Guenter Roeck
2024-04-12 23:18         ` Armin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aace96e3-8645-469b-9056-0199af9d220c@gmx.de \
    --to=w_armin@gmx.de \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jdelvare@suse.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=linux@weissschuh.net \
    --cc=mlj@danelec.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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®