From: Guenter Roeck <linux@roeck-us.net>
To: Conor Dooley <conor@kernel.org>,
Naresh Solanki <naresh.solanki@9elements.com>
Cc: krzysztof.kozlowski+dt@linaro.org,
Jean Delvare <jdelvare@suse.com>,
Rob Herring <robh+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Marcello Sylvester Bauer <sylv@sylv.io>,
linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: hwmon: Add MAX6639
Date: Fri, 4 Aug 2023 09:10:37 -0700 [thread overview]
Message-ID: <3f947ad6-eed6-59ff-e4e6-8b21d90eb803@roeck-us.net> (raw)
In-Reply-To: <20230804-tamper-numbness-0117bb53a921@spud>
On 8/4/23 08:48, Conor Dooley wrote:
> On Thu, Aug 03, 2023 at 04:43:59PM +0200, Naresh Solanki wrote:
>> From: Marcello Sylvester Bauer <sylv@sylv.io>
>>
>> Add binding documentation for Maxim MAX6639 fan-speed controller.
>>
>> Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
>> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
>> ---
>> Changes in V3:
>> - Update title
>> - Add pulses-per-revolution, supplies & interrupts
>> Changes in V2:
>> - Update subject
>> - Drop blank lines
>> ---
>> .../bindings/hwmon/maxim,max6639.yaml | 60 +++++++++++++++++++
>> 1 file changed, 60 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
>> new file mode 100644
>> index 000000000000..b3292061ca58
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
>> @@ -0,0 +1,60 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/maxim,max6639.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Maxim MAX6639 Fan Controller
>> +
>> +maintainers:
>> + - Naresh Solanki <Naresh.Solanki@9elements.com>
>> +
>> +description: |
>> + The MAX6639 is a 2-channel temperature monitor with dual, automatic, PWM
>> + fan-speed controller. It monitors its own temperature and one external
>> + diode-connected transistor or the temperatures of two external diode-connected
>> + transistors, typically available in CPUs, FPGAs, or GPUs.
>
>> + fan-supply:
>> + description: Phandle to the regulator that provides power to the fan.
>
>> + pulses-per-revolution:
>> + description:
>> + Define the number of pulses per fan revolution for each tachometer
>> + input as an integer.
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + enum: [1, 2, 3, 4]
>> + default: 2
>
> Apologies if I am digging up old wounds here, since there was quite a
> bit of back and forth on the last version, but these two newly added
> properties look to be common with the "pwm-fan" and with
> "adi,axi-fan-control". At what point should these live in a common
> schema instead?
>
> Otherwise, this looks okay to me, although I'll leave things to
> Krzysztof since he had a lot to say about the previous version.
>
Rob has said that he won't accept any fan controller bindings without a generic
schema. At the same time he has said that he expects properties such as the
number of pulses per revolution to be attached to a 'fan' description, and he
wants pwm related properties of fan controllers to be modeled as pwm controllers.
And now we have a notion of a regulator providing power to the fan (which again
would be the fan controller, at least in cases where the fan controller
provides direct voltage to the fan). On top of that, this fan-supply property
should presumably, again, be part of a fan description and not be part of the
controller description. I don't think anyone knows how to make this all work
(I for sure don't), so it is very unlikely we'll see a generic fan controller
schema anytime soon.
Given that neither fan-supply nor pulses-per-revolution is implemented in the
driver, and given that I am not aware of any fans which would have a value for
pulses-per-revolution other than 2, my personal suggestion would be to add the
chip to trivial devices and be done with it for the time being.
Guenter
next prev parent reply other threads:[~2023-08-04 16:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 14:43 Naresh Solanki
2023-08-03 14:44 ` [PATCH v3 2/2] hwmon: (max6639) Add compatible string Naresh Solanki
2023-08-10 4:03 ` Guenter Roeck
2023-08-04 15:48 ` [PATCH v3 1/2] dt-bindings: hwmon: Add MAX6639 Conor Dooley
2023-08-04 16:10 ` Guenter Roeck [this message]
2023-08-05 20:26 ` Krzysztof Kozlowski
2023-08-10 23:11 ` Rob Herring
2023-08-10 23:54 ` Guenter Roeck
2023-08-11 10:42 ` Naresh Solanki
2023-08-05 20:24 ` Krzysztof Kozlowski
2023-08-10 4:01 ` Guenter Roeck
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=3f947ad6-eed6-59ff-e4e6-8b21d90eb803@roeck-us.net \
--to=linux@roeck-us.net \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jdelvare@suse.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naresh.solanki@9elements.com \
--cc=robh+dt@kernel.org \
--cc=sylv@sylv.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®