Re: [PATCH] [RFC] hwmon: nct6775: Register fan PWMs as PWM chip

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

On 2/27/26 12:02, Uwe Kleine-König wrote:
> Hello,
> 
> On Fri, Feb 27, 2026 at 12:17:00AM -0800, Guenter Roeck wrote:
>> Hi Richard,
>>
>> On 2/26/26 23:46, Richard Weinberger wrote:
>>> Hello Guenter,
>>>
>>> ----- Ursprüngliche Mail -----
>>>> Von: "Guenter Roeck" <linux@roeck-us.net>
>>>>>     - Exporting a PWM for external use is only allowed when the fan mode
>>>>>       is set to manual or off.
>>>>>     - As soon as a PWM is exported, changing its configuration is no
>>>>>       longer possible through the hwmon sysfs interface, reading is
>>>>>       still allowed.
>>>>>     - Changing the PWM period is not supported. IMHO, it is too risky
>>>>>       since the PWMs usually control system fans and similar components.
>>>>>     - Reading and decoding the current PWM period is only supported for
>>>>>       one chip variant so far, for all other chips, a fixed period of
>>>>>       100ms is assumed.
>>>>>
>>>>
>>>> This is a good start, but I'll want to see stronger safeguards.
>>>> - Creating a pwmchip entry for a pwm channel must be triggered by
>>>>     device property data, obtained either from devicetree or through
>>>>     DMI or through device properties embedded in ACPI data. For each
>>>>     channel, this must be confirmed by checking that the channel is
>>>>     not associated with a fan control channel.
>>>
>>> In my case it's a x86 based industrial PC with direct access.
>>> What safeguard do you suggest in this case? A module parameter?
>>>
>>
>> Presumably it has DMI information or some other means to identify the system.
>> That information can be used to set device properties, which would then be used
>> in the probe function to determine if a channel is modeled as pwm channel.
>> See device_add_software_node() and friends to get an idea how that works.
>>
>> How exactly those properties would look like needs to be documented in
>> nuvoton,nct6775.yaml. I'd assume that the pwm channels would be described
>> in there just like for any other pwm chips.
>>
>>> Also for ACPI data, what exactly do you have in mind?
>>>
>> ACPI can be used to provide devicetree properties. The information is embedded
>> in the DSDT table. Conceptually that is identical to devicetree data. That is
>> not something you need to be concerned about unless you are responsible for that
>> system and in control of the firmware. Technically the company selling that
>> industrial PC should provide the information in the DSDT table, but of course
>> that needs to be standardized first (and then they would have to actually use it).
> 
> That would imply that derRichard has to update the BIOS, or at least
> fake some ACPI tables, right?
> 
No, I didn't say that. The board manufacturer could do that, but checking
the DMI data in the init function and using software nodes to pass properties
to the driver would do the trick.

> For me it would be good enough if the first consumer of a channel "wins"
> and others get a -EBUSY. Compared to describing that in dt or acpi this
> has the advantage that the use can be changed without a reboot.
> 

No, this is not acceptable. In almost all cases the pwm output will be
connected to a fan, it will be configured by the BIOS, and it may (and
likely will) be configured for DC output instead of pwm output. Changing
that randomly with "first consumer wins" is simply not acceptable.
This will have to be static and well defined.

Guenter