linux-kernel - Re: [PATCH v2 1/2] dt-bindings: hwmon: Add max6639

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: <3a912cab-001f-a70b-394d-71370fc482e5@roeck-us.net>
Date:   Wed, 19 Jul 2023 10:39:39 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Naresh Solanki <naresh.solanki@...ements.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Jean Delvare <jdelvare@...e.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Cc:     Marcello Sylvester Bauer <sylv@...v.io>,
        linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: Add max6639

On 5/4/23 04:36, Naresh Solanki wrote:
> Hi Krzysztof,
> 
[ ... ]
>>
>> No, we cannot, because we asked you to fix things there. Your entire
>> explanation about compatible and driver is not related to the comment
>> you received: bindings should be complete. You argue that bindings do
>> not have to be complete, because of something with driver. This is not
>> related. Bindings are not for driver.
> 
> I understand that complete bindings are important, but as the driver is already merged and functional, my immediate goal is to enable its use on my machine. I will work on a separate patch to include the interrupts in both binding & driver.
> 

As a follow-up, since it came up in a separate context:

Bindings and driver are independent of each other. _Bindings_
are supposed to be complete. However, the existence of a property
in the bindings description does not have to be reflected in
the driver.

FWIW, you _could_ have added the device to the list of trivial
devices. The only really mandatory property is vdd, and every
chip has that. All other properties are really about configuration
and/or fan properties, and I don't even know how to describe fan
properties (such as pulses per revolution, pwm parameters,
fan speed limits, the relationship between pwm outputs
and fan inputs, the relationship between fan speed input
and pwm output, or fan spin-up requirements) in devicetree.

Guenter