linux-kernel - Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879

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: <35a9399e-819a-400c-b321-099f8bc9df90@linaro.org>
Date: Fri, 5 Apr 2024 08:35:05 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Matti Vaittinen <mazziesaccount@...il.com>,
 Andreas Kemnade <andreas@...nade.info>
Cc: lee@...nel.org, robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
 conor+dt@...nel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879

On 05/04/2024 08:01, Matti Vaittinen wrote:
> On 4/4/24 15:04, Krzysztof Kozlowski wrote:
>> On 04/04/2024 12:30, Andreas Kemnade wrote:
>>> On Thu, 4 Apr 2024 08:59:54 +0200
>>> Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> wrote:
>>>
>>>> On 02/04/2024 21:35, Andreas Kemnade wrote:
>>>>> As this chip was seen in several devices in the wild, add it.
>>>>>
>>>>> Signed-off-by: Andreas Kemnade <andreas@...nade.info>
>>>>> Suggested-by: Matti Vaittinen <mazziesaccount@...il.com>
>>>>> ---
>>>>>   Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 4 +++-
>>>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>> index 0b62f854bf6b..e4df09e8961c 100644
>>>>> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>> @@ -17,7 +17,9 @@ description: |
>>>>>   
>>>>>   properties:
>>>>>     compatible:
>>>>> -    const: rohm,bd71828
>>>>> +    enum:
>>>>> +      - rohm,bd71828
>>>>> +      - rohm,bd71879
>>>>
>>>> In your second commit you claim they are compatible, so why they are not
>>>> marked as such?
>>>>
>>> so you mean allowing
>>>
>>> compatible = "rohm,bd71828"
>>> and
>>> compatible = "rohm,bd71879", "rohm,bd71828"
> 
> 
> This makes me slightly nervous. It wouldn't be the first time when I've 
> been told "they are similar", and later the reality has turned out to be 
> "they are similar, except...". Furthermore, even if these devices seem 
> similar to software (which is what the comment in the MFD driver is 
> referring to), it does not mean these devices are 100% electrically 
> compatible so that they could be used as a "drop-in" replacement to each 
> others. I wouldn't guarantee that.

compatibility does not mean that. It is only about software interface.

> 
> Furthermore, my current understanding is that the BD71828 was a model 
> that was used for a limited purposes. So, maybe creating an dt-entry like:
> compatible = "rohm,bd71879", "rohm,bd71828"
> 
> might not prove to be too useful. (But I'm not 100% certain on this).
> 
>> Yes. If there are reasons against, please briefly mention them in commit
>> msg.
> 
> I would like to understand the rationale for allowing:
> compatible = "rohm,bd71879", "rohm,bd71828".
> 
> Is the intention to:
> 1) allow boards which tell the software that "the hardware may be 
> bd71828 or bd71879", or
> 2) to tell a binding reader that these ICs are likely to be usable as 
> replacements to each others?
> (Or, is there some other rationale beyond these?)

None of these. Compatibility means that software can use fallback
compatible as matching mechanism and everything will work fine or with
reduced set of features, but still working.

> 
> If it's 1), then I see limited sense in doing so, while I expect that 
> not so many bd71828 variants will be seen out there - and at least not 
> in that many different products. If it's the 2), then I wouldn't say we 
> have the facts to do this.
> And, as always, if there is 3), 4), ... - I am keen to learn :)
> 


Best regards,
Krzysztof