linux-kernel - Re: [PATCH v2 1/2] dt-bindings: trivial-devices: add ltp8800

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: <bf8e8a47-19a2-4bee-8044-4ca25c17115f@roeck-us.net>
Date: Wed, 6 Nov 2024 10:23:27 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Conor Dooley <conor@...nel.org>
Cc: Cedric Encarnacion <cedricjustine.encarnacion@...log.com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-i2c@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
 Jonathan Corbet <corbet@....net>,
 Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Peter Yin <peteryin.openbmc@...il.com>,
 Noah Wang <noahwang.wang@...look.com>, Marek Vasut <marex@...x.de>,
 Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH v2 1/2] dt-bindings: trivial-devices: add ltp8800

On 11/6/24 08:46, Conor Dooley wrote:
> On Wed, Nov 06, 2024 at 08:35:33AM -0800, Guenter Roeck wrote:
>> On 11/6/24 08:06, Conor Dooley wrote:
>>> On Tue, Nov 05, 2024 at 08:34:01PM -0800, Guenter Roeck wrote:
>>>> On 11/5/24 19:09, Cedric Encarnacion wrote:
>>>>> Add Analog Devices LTP8800-1A, LTP8800-2, and LTP8800-4A DC/DC μModule
>>>>> regulator.
>>>
>>> A single compatible for 3 devices is highly suspect. What is
>>> different between these devices?
>>>
>>
>> The maximum supported current is different.
>>
>> -2:  135A
>> -1A: 150A
>> -4A: 200A
>>
>> Programming is exactly the same, which is why I had asked the submitter to use
>> a single compatible property. Sorry for that if it is inappropriate.
>>
>> Is there some guidance explaining when to use a single vs. multiple compatible
>> properties for different chip variants ?
> 
> TBH, I'm biased and a bit paranoid, so I'd probably give them all
> compatibles and set one of them as a fallback. If the programming model

Sometimes compatibles have been rejected because a new chip variant is fully
compatible with an existing one. Now you are doing the opposite. A document
providing reliable guidance one way or the other would really be useful.

Thanks,
Guenter