From: Richard Weinberger <richard@nod.at>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-pwm <linux-pwm@vger.kernel.org>,
linux-hwmon <linux-hwmon@vger.kernel.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"julian friedrich" <julian.friedrich@frequentis.com>
Subject: Re: [PATCH] [RFC] hwmon: nct6775: Register fan PWMs as PWM chip
Date: Fri, 27 Feb 2026 08:46:51 +0100 (CET) [thread overview]
Message-ID: <1892064865.155.1772178411224.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <9c733024-8ad6-459d-ae5a-a9825f85c506@roeck-us.net>
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?
Also for ACPI data, what exactly do you have in mind?
> - If a pwm channel is configured as pwmchip, it must not be used for fan
> control, meaning the hwmon properties associated with that channel
> must not be created.
Ok.
> This will retain current functionality while enabling support for using
> pwm channels for purposes other than fan control.
>
> Thanks,
> Guenter
next prev parent reply other threads:[~2026-02-27 7:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 12:51 [PATCH] [RFC] hwmon: nct6775: Register fan PWMs as PWM chip Richard Weinberger
2026-02-26 17:54 ` Uwe Kleine-König
2026-02-26 18:36 ` Richard Weinberger
2026-02-27 19:57 ` Uwe Kleine-König
2026-02-26 22:38 ` Guenter Roeck
2026-02-27 7:46 ` Richard Weinberger [this message]
2026-02-27 8:17 ` Guenter Roeck
2026-02-27 20:02 ` Uwe Kleine-König
2026-02-27 20:59 ` Guenter Roeck
2026-04-14 9:48 ` Uwe Kleine-König
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=1892064865.155.1772178411224.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=julian.friedrich@frequentis.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=ukleinek@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.