linux-kernel - Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add lt3074

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: <190c4a14-167a-4f72-8aed-477d4a401d20@roeck-us.net>
Date: Mon, 24 Mar 2025 06:58:15 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Krzysztof Kozlowski <krzk@...nel.org>,
 "Encarnacion, Cedric justine" <Cedricjustine.Encarnacion@...log.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Jean Delvare <jdelvare@...e.com>,
 Jonathan Corbet <corbet@....net>,
 Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add lt3074

On 3/24/25 00:16, Krzysztof Kozlowski wrote:
> On 21/03/2025 18:24, Guenter Roeck wrote:
>>>
>>> Figured. As it turns out, there is also a patch series pending which tries
>>> to fix the problem for ir38060 by changing its bindings.
>>>
>>> I'll dig up my patch series to add a new macro and send it out as RFT.
>>>
>>
>> Question for DT maintainers:
>>
>> Existing bindings, such as
>> 	Documentation/devicetree/bindings/regulator/mps,mpq2286.yaml
>> expect a nested regulators node even though there is only a single
>> regulator. What is the correct approach: Keep the nesting requirement
>> for those regulators as is (even if there are no in-tree bindings
>> using them), or update the code and the bindings to drop the nesting ?
>>
> I would recommend keep the nesting, so don't touch it. There might be
> external users, other projects relying on this. You can however
> deprecate old node (nesting), if the driver can support both. Not sure
> if it is worth the effort.
> 
That is not in driver control: If regulators_node is set by the driver,
the regulator subsystem mandates the sub-node.

Thanks,
Guenter