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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YgqMZhNhMRgO0V8t@sirena.org.uk>
Date:   Mon, 14 Feb 2022 17:07:50 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
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 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.

> 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.

Coupling is already supported - it doesn't require anything on the part
of the driver, it's about defining the relationships between supplies
rather than anything the driver or device does.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)