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] [day] [month] [year] [list]

Date:   Mon, 14 Feb 2022 18:28:39 +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 18:07, Mark Brown wrote:
> On Mon, Feb 14, 2022 at 06:01:17PM +0100, Krzysztof Kozlowski wrote:
> 
>> 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.
> 
> We should have a way of specifying generic properties that doesn't
> require us to go through every single user of a binding and updating
> them all, then auditing by hand any new users to make sure they didn't
> forget one of the generic properties.  This is just error prone and
> miserable, especially when most of the checking is done by hand rather
> than automated.

I see. The hardware really does not support most of core regulator
features, so if we switch to your proposal
(unevaluatedProperties:false), the DTS could contain something which is
good from the core regulator point of view, but does not fit at all this
hardware.

A disallow/deny-list could solve it... but it also does not scale.

Best regards,
Krzysztof