linux-kernel - Re: [PATCH 4/4] dt-bindings: hwmon: ti,ina238: add ti,ina237

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]

Date:   Wed, 25 Oct 2023 16:22:27 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Richard Leitner <richard.leitner@...ux.dev>,
        Conor Dooley <conor@...nel.org>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Jean Delvare <jdelvare@...e.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 4/4] dt-bindings: hwmon: ti,ina238: add ti,ina237

On 25/10/2023 16:13, Richard Leitner wrote:
> On Wed, Oct 25, 2023 at 02:58:44PM +0100, Conor Dooley wrote:
>> On Wed, Oct 25, 2023 at 10:34:14AM +0000, Richard Leitner wrote:
>>> Add ti,ina237 binding to ti,ina238 as they share the same driver.
>>>
>>> Signed-off-by: Richard Leitner <richard.leitner@...ux.dev>
>>> ---
>>>  Documentation/devicetree/bindings/hwmon/ti,ina238.yaml | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml
>>> index aba89e5f34b3..17408076696c 100644
>>> --- a/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml
>>> +++ b/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml
>>> @@ -22,6 +22,7 @@ description: |
>>>  properties:
>>>    compatible:
>>>      enum:
>>> +      - ti,ina237
>>
>> The driver patch you have done implies no difference between the
>> programming model for both of these devices. It'd seem to make more sense
>> for the ina237 to fall back to the ina238, thereby requiring no change in
>> the driver to support it.
> 
> Thanks for the quick feedback, Conor.
> 
> I first thought of just mentioning the ina237 in the documentation as
> "compatible" to the ina238. But IMHO it is better understandable if it's
> listed as compatible.

Conor did not oppose listing it. The point is to use fall-back.

> 
> And I would strongly encourage mentioning it somewhere (documentation or
> compatible). So other people using the ina237 are able to find it and
> don't have to compare the datasheets by themselves to find the right
> driver.

Sure, there is plenty of space in the driver code (.c or Kconfig) to
document whatever you wish. We focus here on the bindings, though.

Best regards,
Krzysztof