linux-kernel - Re: [PATCH v7 1/3] dt-bindings: hwmon: Add adt7475 fan/pwm properties

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d538cd42-f8b3-43cb-897d-d60c3af57300@alliedtelesis.co.nz>
Date: Mon, 2 Jun 2025 20:52:56 +0000
From: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To: Uwe Kleine-König <ukleinek@...nel.org>
CC: "jdelvare@...e.com" <jdelvare@...e.com>, "linux@...ck-us.net"
	<linux@...ck-us.net>, "robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "linux-hwmon@...r.kernel.org"
	<linux-hwmon@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-pwm@...r.kernel.org"
	<linux-pwm@...r.kernel.org>
Subject: Re: [PATCH v7 1/3] dt-bindings: hwmon: Add adt7475 fan/pwm properties


On 30/05/2025 21:38, Uwe Kleine-König wrote:
> Hello Chris,
>
> On Wed, May 28, 2025 at 09:18:37PM +0000, Chris Packham wrote:
>> On 28/05/2025 18:10, Uwe Kleine-König wrote:
>>> If I understand correctly you need the default value for duty to
>>> statically setup (or only initialize?) a fan, right?
>> Correct.
>>
>>> I'm not sure I like
>>> extending #pwm-cells for a default duty value. Thinking about that a
>>> while I'd prefer a binding that looks more like the clock configuration
>>> stuff because actually having the period and flags as part of the
>>> reference to the PWM to be used is also a bit strange. So I imagine
>>> something like:
>>>
>>> 	mypwm: pwm {
>>> 		compatible = "...."
>>> 		#pwm-cells = <1>;
>>> 	};
>>>
>>> 	fan {
>>> 		compatible = "pwm-fan";
>>> 		pwms = <&mypwm 1>;
>>> 		assigned-pwms = <&mypwm>;
>>> 		assigned-pwm-default-period-lengths-ns = <40000>;
>>> 		assigned-pwm-default-flags = <PWM_POLARITY_INVERTED>;
>>> 	};
>>>
>>> Then specifying a period (or later a duty cycle length) would be
>>> optional and could be provided iff the device needs that for operation.
>> The frequency and flags were already part of the standard #pwm-cells
>> which I think is why I was encouraged to use them.
> Yeah, that part is fine. This might not be the long-term future, but
> today that's the norm.
>
>> I was also trying to get something that would work as an ACPI overlay
>> which turned out to be really hard.
> I don't know enough about ACPI to be helpful with this quest.
>
>>> My mail was just me being frustrated about another special case that I'd
>>> have to handle if I go into that direction. I should have been more
>>> attentive to that development before it entered the mainline.
>> I'd be happy to deprecate the 4 cell thing and replace it with 3 cell +
>> vendor property for the default period if that helps.
> I wonder how other similar devices determine the default duty cycle.
> Isn't the norm to make the fan rotate at max speed and then when
> userspace takes over it's speeded down?

Yes that is the normal (and sensible thing do to). But occasionally 
hardware designers like to use incredibly over spec'd  fans that are 
just ridiculously noisy. On some products I've worked on we added basic 
fan control to u-boot so we could silence the fans early in the boot. I 
also gather that in the PC world the fan control is often done 
externally to the OS. In the specific case were I needed this 
functionality it was an embedded x86_64 so I had neither U-Boot nor a BMC.