devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Conor Dooley <conor@kernel.org>,
	Delphine_CC_Chiu/WYHQ/Wiwynn <Delphine_CC_Chiu@wiwynn.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	"patrick@stwcx.xyz" <patrick@stwcx.xyz>,
	Jean Delvare <jdelvare@suse.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] dt-bindings: hwmon: add MAX31790
Date: Fri, 22 Sep 2023 07:42:42 -0700	[thread overview]
Message-ID: <ceea0b12-9165-a9f6-cbd1-b25c07c75efb@roeck-us.net> (raw)
In-Reply-To: <20230922-washday-primer-af8dcf1cde7d@spud>

On 9/22/23 02:53, Conor Dooley wrote:
> On Fri, Sep 22, 2023 at 02:33:06AM +0000, Delphine_CC_Chiu/WYHQ/Wiwynn wrote:
>>>> On Fri, Sep 15, 2023 at 02:29:24PM +0800, Delphine CC Chiu wrote:
> 
>>>>> +  pwm-as-tach:
>>>>
>>>> I don't see any other users of this in-tree, so you'd need a vendor
>>>> prefix. That said, I'm once bitten, twice shy about fan related
>>>> properties in hwmon, so I would definitely like Rob to comment on this
>>>> whole binding.
>>>
>>> Please see this[1] and comment on it to ensure it meets your needs.
>>> Otherwise, omit any fan related properties for now.
>>>
>> This property could only be used in max31790 driver. Would it be ok if we add
>> vendor prefix like "maxim, pwm-as-tach"?
> 
> I think the answer to this is a pretty straightforward no. The goal is
> to create a set of common fan properties that works for multiple
> usecases, not create one specifically for each user...
> 

Another chip with configurable channel configuration is nct7802, where
individual channels can be configured as temperature or voltage sensor.
We are using sensor-type to select the mode in that driver. Maybe something
similar would make sense / be acceptable here.

>>>> +examples:
>>>> +  - |
>>>> +    i2c {
>>>> +      #address-cells = <1>;
>>>> +      #size-cells = <0>;
>>>> +
>>>> +      pwm@20 {
>>>> +        compatible = "maxim,max31790";
>>>> +        reg = <0x20>;
>>>> +        pwm-as-tach = <2 5>;
>>>
>>> This would be <2>, <5>; no?
>>>
>> I refer to the other binding documents in hwmon and most of them were using
>> the format like <2 5> as an array.
> 
> Which also makes this moot, since it'll be going away.
> 
>>>> diff --git a/MAINTAINERS b/MAINTAINERS index
>>>> c8fdd0d03907..97e13b6bf51d 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -1371,6 +1371,12 @@ F:
>>>        Documentation/devicetree/bindings/hwmon/adi,max31760.yaml
>>>>   F: Documentation/hwmon/max31760.rst
>>>>   F: drivers/hwmon/max31760.c
>>>>
>>>> +ANALOG DEVICES INC MAX31790 DRIVER
>>>> +M: Delphine CC Chiu  <Delphine_CC_Chiu@wiwynn.com>
>>>> +S: Odd Fixes
>>>
>>> This is a pretty odd status for something you're newly adding.
>>> How come it's not going to be maintained?
>>>
>> We are not the authors of this driver but we want to add a feature to
>> config PWM as TACH that was descripted in the datasheet of MAX31790.
>> Should we set the status to maintained?
> 
> It's really up to you. I just found it curious & wanted to ask why it
> was that way.
> 

It is misleading because it downgrades the driver from "supported"
(like all other hwmon drivers) to "odd fixes".

Guenter


      reply	other threads:[~2023-09-22 14:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15  6:29 [PATCH v2 0/2] hwmon: max31790: support to config PWM as TACH Delphine CC Chiu
2023-09-15  6:29 ` [PATCH v2 1/2] " Delphine CC Chiu
2023-09-15  6:29 ` [PATCH v2 2/2] dt-bindings: hwmon: add MAX31790 Delphine CC Chiu
2023-09-15 14:50   ` Conor Dooley
2023-09-15 15:20     ` Rob Herring
2023-09-22  2:33       ` Delphine_CC_Chiu/WYHQ/Wiwynn
2023-09-22  9:53         ` Conor Dooley
2023-09-22 14:42           ` Guenter Roeck [this message]

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=ceea0b12-9165-a9f6-cbd1-b25c07c75efb@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=Delphine_CC_Chiu@wiwynn.com \
    --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=patrick@stwcx.xyz \
    --cc=robh+dt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).