linux-kernel - Re: [PATCH v2 3/4] regulator: dt-bindings: maxim,max77693: convert to dtschema

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:   Mon, 14 Feb 2022 18:01:17 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Chanwoo Choi <cw00.choi@...sung.com>, Pavel Machek <pavel@....cz>,
        Rob Herring <robh+dt@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Sebastian Reichel <sre@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
        devicetree@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 3/4] regulator: dt-bindings: maxim,max77693: convert to
 dtschema

On 14/02/2022 17:51, Mark Brown wrote:
> On Mon, Feb 14, 2022 at 05:45:40PM +0100, Krzysztof Kozlowski wrote:
>> On 14/02/2022 17:41, Mark Brown wrote:
>>>> +    properties:
>>>> +      regulator-name: true
>>>> +      regulator-always-on: true
>>>> +      regulator-boot-on: true
> 
>>> Why are these specific generic regulator properties enumerated?  
> 
>> additionalProperties=false is used, so all properties, also ones from
>> regulator.yaml, have to be mentioned.
> 
>> Why this approach was used? Because the hardware here is very limited,
>> so no other properties are expected. No other features are supported.
> 
> That's not going to scale well if we add any new features in the core,
> and doesn't include things like coupling which could be applied to any
> regulator.

Relaxing constraints - removing required nodes and using
uneavluatedProperties=false - is still possible. Unlike the other way if
we ever wanted to restrict too flexible bindings.

You mantioned new features - this approach does not change that. If you
add new properties to common schema, you already alter bindings. Just
because we use common part, it does not change the fact that it is a
bindings change. Adding new features in common schema is the same
binding change as adding new feature in the specific binding, except
more work.

I guess you though that work in scaling, so yes, this scales worse. The
benefit is that this really restricts usage of regulator to what is
supported, so allows to detect wrongly configured DTS.

Once coupling (or any other feature) is supported, each of such
restricted regulator bindings should be independently revised, instead
of adding this new feature to everything.

Best regards,
Krzysztof