From: Guenter Roeck <linux@roeck-us.net>
To: "Thomas Weißschuh" <thomas@weissschuh.net>
Cc: Sung-Chi Li <lschyi@chromium.org>,
Jean Delvare <jdelvare@suse.com>,
Benson Leung <bleung@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
chrome-platform@lists.linux.dev, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] hwmon: (cros_ec) Add set and get target fan RPM function
Date: Sat, 22 Mar 2025 09:10:40 -0700 [thread overview]
Message-ID: <42c49b0b-cef0-49ca-a5b2-5bb05eae8dec@roeck-us.net> (raw)
In-Reply-To: <780ce6e8-11fc-42be-b4a7-9cffbf811d78@t-8ch.de>
On 3/22/25 08:23, Thomas Weißschuh wrote:
> On 2025-03-22 07:12:48-0700, Guenter Roeck wrote:
>> On 3/22/25 06:55, Thomas Weißschuh wrote:
>>> On 2025-03-18 15:45:23+0800, Sung-Chi Li wrote:
>>>> The ChromeOS embedded controller (EC) supports closed loop fan speed
>>>> control, so add the fan target attribute under hwmon framework, such
>>>> that kernel can expose reading and specifying the desired fan RPM for
>>>> fans connected to the EC.
>>>>
>>>> When probing the cros_ec hwmon module, we also check the supported
>>>> command version of setting target fan RPM. This commit implements the
>>>> version 0 of getting the target fan RPM, which can only read the target
>>>> RPM of the first fan. This commit also implements the version 1 of
>>>> setting the target fan RPM to each fan respectively.
>>>>
>>>> Signed-off-by: Sung-Chi Li <lschyi@chromium.org>
>>>> ---
>>>> ChromeOS embedded controller (EC) supports closed-loop fan control. We
>>>> anticipate to have the fan related control from the kernel side, so this
>>>> series register the HWMON_F_TARGET attribute, and implement the read and
>>>> write function for setting/reading the target fan RPM from the EC side.
>>>
>>> Should it be possible to switch back to automatic control?
>>> I can't find anything in the hwmon ABI about it.
>>> And neither in the CrOS EC source.
>>>
>>> Am I missing something?
>>>
>>
>> Not sure I understand the context, but the fan control method is normally
>> selected with pwmX_enable, which is defined as
>>
>> Fan speed control method:
>>
>> - 0: no fan speed control (i.e. fan at full speed)
>> - 1: manual fan speed control enabled (using `pwmY`)
>> - 2+: automatic fan speed control enabled
>
> So far I associated pwmY_enable = 1 with the pwmY attribute.
> Also controlling it through fanY_target does make sense though.
> It could be clearer from the docs IMHO.
>
> That also means that the patch under discussion needs to implement the
> pwmY_enable attribute.
>
Does it ? Does setting the target fan speed automatically change the fan
control method ? Normally that is orthogonal: One does not necessarily
want to enable a specific fan control method after setting a single related
attribute, but do that only after all attributes have been set.
For example, there could be another attribute specifying how fast the fan
speed should be adjusted, or there could be minimum and/or maximum permitted
pwm values. I am not saying that this is the case here, but setting a target
fan speed should not automatically change the fan control method.
Guenter
next prev parent reply other threads:[~2025-03-22 16:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 7:45 [PATCH v3] hwmon: (cros_ec) Add set and get target fan RPM function Sung-Chi Li
2025-03-22 13:55 ` Thomas Weißschuh
2025-03-22 14:12 ` Guenter Roeck
2025-03-22 15:23 ` Thomas Weißschuh
2025-03-22 15:45 ` Guenter Roeck
2025-03-23 16:08 ` Thomas Weißschuh
2025-03-22 16:10 ` Guenter Roeck [this message]
2025-03-23 16:05 ` Thomas Weißschuh
2025-03-23 16:22 ` Guenter Roeck
2025-03-25 7:16 ` Sung-Chi Li
2025-03-25 12:55 ` Guenter Roeck
2025-03-26 2:44 ` Sung-Chi Li
2025-03-22 16:06 ` Guenter Roeck
2025-03-23 16:16 ` Thomas Weißschuh
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=42c49b0b-cef0-49ca-a5b2-5bb05eae8dec@roeck-us.net \
--to=linux@roeck-us.net \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=groeck@chromium.org \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lschyi@chromium.org \
--cc=thomas@weissschuh.net \
/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