linux-kernel - Re: [PATCH v2 1/2] dt-bindings: hwmon: amc6821: add PWM polarity

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1c7e20e1-b139-4fc4-8127-f409ce9a3cf4@roeck-us.net>
Date: Wed, 19 Mar 2025 06:44:35 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Francesco Dolcini <francesco@...cini.it>, Rob Herring <robh@...nel.org>,
 Quentin Schulz <quentin.schulz@...rry.de>
Cc: Jean Delvare <jdelvare@...e.com>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Farouk Bouabid <farouk.bouabid@...rry.de>,
 Francesco Dolcini <francesco.dolcini@...adex.com>,
 linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: amc6821: add PWM polarity

On 3/19/25 03:12, Francesco Dolcini wrote:
> Hello Rob and all,
> 
> On Wed, Feb 26, 2025 at 02:58:06PM +0100, Francesco Dolcini wrote:
>> On Wed, Feb 26, 2025 at 07:49:22AM -0600, Rob Herring wrote:
>>> On Mon, Feb 24, 2025 at 07:08:00PM +0100, Francesco Dolcini wrote:
>>>> From: Francesco Dolcini <francesco.dolcini@...adex.com>
>>>>
>>>> Add property to describe the PWM-Out pin polarity.
>>>
>>> Why doesn't the invert support in the pwm binding work for you? Yes, I
>>> read the discussion, but don't remember the conclusion and you need to
>>> justify it here.
>>
>> This chip is not a PWM controller, it is a FAN controller.
>>
>> The HW has a PWM pin output that is used to control the fan, but the
>> device is not modelled as a PWM controller (correctly, given that is not
>> such a device) and the OS does not control the PWM, the chip reads the
>> temperature and decide the PWM duty cycle accordingly in an autonomous
>> way.
> 
> Can you advise on how to move this forward? Is my explanation good
> enough or some more clarification is needed? Should I send a v3
> incorporating such a comment into the commit message? Anything else?
> 

DT maintainers insist that pwm properties are described using pwm cells.
That does not mean that the driver has to implement a pwm controller
(and I would resist doing that, because it is pointless), just that
the chip's pwm properties are described this way. That is indeed a deviation
from older devicetree files, where "inverted" properties were acceptable.

I don't know if there is a means to avoid that. Some devicetree files
don't mention pwm in the property name. See nxp,inverted-out or
atmel,lcdcon-backlight-inverted for examples. I suspect that is no longer
acceptable, though. The easiest would probably be to define optional
minimal pwm bindings for the chip. Unless I am missing something, that
would just be the pwm polarity, so you would have a single pwm cell.
Something like

   '#pwm-cells':
     const: 1
     description: |
       Number of cells in a PWM specifier.
       - cell 0: The PWM polarity: 0 or PWM_POLARITY_INVERTED

and then something like

     fan_controller: fan@18 {
	compatible = "ti,amc6821";
	reg = <0x18>;
	#pwm-cells = <1>;

	pwms = <&fan_controller PWM_POLARITY_INVERTED>;
     };	

That may require some tweaking though; I think #pwm-cells may apply to the
children of a property, not to the property itself.

Guenter