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: Sat, 13 Apr 2024 01:18:51 +0200 [thread overview]
Message-ID: <77d99950-5abe-4e36-822f-351cd3c51954@gmx.de> (raw)
In-Reply-To: <cff6f5f3-d883-4509-819d-9d2307bdcd56@roeck-us.net>
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
prev parent reply other threads:[~2024-04-12 23:19 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
2024-04-12 21:01 ` Guenter Roeck
2024-04-12 23:18 ` Armin Wolf [this message]
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=77d99950-5abe-4e36-822f-351cd3c51954@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).