linux-kernel - Re: [PATCH] ACPI: fan: Add hwmon support

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]

Message-ID: <36a8ebff-8a89-44e0-9b30-374913bd8cbd@gmx.de>
Date: Mon, 8 Apr 2024 19:12:46 +0200
From: Armin Wolf <W_Armin@....de>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: mlj@...elec.com, rafael.j.wysocki@...el.com, lenb@...nel.org,
 linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
 platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH] ACPI: fan: Add hwmon support

Am 08.04.24 um 17:48 schrieb Ilpo Järvinen:

> On Mon, 8 Apr 2024, Armin Wolf wrote:
>
>> Currently, the driver does only supports 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".
>>
>> Signed-off-by: Armin Wolf <W_Armin@....de>
>> ---
>>   drivers/acpi/Makefile    |  1 +
>>   drivers/acpi/fan.h       |  2 ++
>>   drivers/acpi/fan_core.c  |  7 ++++
>>   drivers/acpi/fan_hwmon.c | 78 ++++++++++++++++++++++++++++++++++++++++
>>   4 files changed, 88 insertions(+)
>>   create mode 100644 drivers/acpi/fan_hwmon.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index d69d5444acdb..9a2e03acc1be 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -83,6 +83,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-objs			+= 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 e7b4b4e4a55e..45c2637566da 100644
>> --- a/drivers/acpi/fan.h
>> +++ b/drivers/acpi/fan.h
>> @@ -56,4 +56,6 @@ 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);
>> +
>> +int devm_acpi_fan_create_hwmon(struct acpi_device *device);
>>   #endif
>> diff --git a/drivers/acpi/fan_core.c b/drivers/acpi/fan_core.c
>> index ff72e4ef8738..6bbdbb914e95 100644
>> --- a/drivers/acpi/fan_core.c
>> +++ b/drivers/acpi/fan_core.c
>> @@ -7,6 +7,7 @@
>>    *  Copyright (C) 2022 Intel Corporation. All rights reserved.
>>    */
>>
>> +#include <linux/kconfig.h>
>>   #include <linux/kernel.h>
>>   #include <linux/module.h>
>>   #include <linux/init.h>
>> @@ -336,6 +337,12 @@ static int acpi_fan_probe(struct platform_device *pdev)
>>   		if (result)
>>   			return result;
>>
>> +		if (IS_REACHABLE(CONFIG_HWMON)) {
>> +			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..4f2bec8664f4
>> --- /dev/null
>> +++ b/drivers/acpi/fan_hwmon.c
>> @@ -0,0 +1,78 @@
>> +// 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@....de>
>> + */
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/limits.h>
>> +
>> +#include "fan.h"
>> +
>> +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_fst fst;
>> +	int ret;
>> +
>> +	switch (type) {
>> +	case hwmon_fan:
>> +		ret = acpi_fan_get_fst(adev, &fst);
>> +		if (ret < 0)
>> +			return ret;
>> +
>> +		switch (attr) {
>> +		case hwmon_fan_input:
>> +			if (fst.speed > LONG_MAX)
>> +				return -EOVERFLOW;
>> +
>> +			*val = fst.speed;
>> +			return 0;
>> +		case hwmon_fan_fault:
>> +			*val = (fst.speed == U32_MAX);
>> +			return 0;
> Is it okay to return 0 in this case?

Hi,

i think so, since the value of the attribute (with the meaning of "is the rpm value ok?") is being
correctly stored in val. If acpi_fan_get_fst() fails, we already return a negative error code.

Thanks,
Armin Wolf

>> +		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_FAULT),
> One line.
>