Re: [PATCH v3] hwmon: (cros_ec) Add set and get target fan RPM function

[Guenter Roeck <linux@roeck-us.net>]

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 is chip specific, and needs to be documented in the chip documentation.

> 
> That also means that the patch under discussion needs to implement the
> pwmY_enable attribute.
> 
> One more thing I have wondered about before:
> Is pwmY always refering to the same thing as the matching fanY?
> 

That used to be the case when the ABI was defined, and it is for the most part
still the case. However, nowadays there are chips which permit dynamic assignment
of pwm channels to fan tachometer channels. Recent Aspeed SoCs are a perfect
example. On those, the pwm <->fan mapping is completely dynamic. How to handle
and express that in devicetree (which is where it is really needed) is still
being worked out, though I think we are slowly getting there.

Of course that means that the correlation isn't typically spelled out explicitly
since it _used_ to be implicit.

Guenter