Thread (18 messages) 18 messages, 5 authors, 2022-02-14

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

From: Krzysztof Kozlowski <hidden>
Date: 2022-02-14 17:28:47
Also in: linux-leds, linux-pm, lkml

On 14/02/2022 18:07, Mark Brown wrote:
On Mon, Feb 14, 2022 at 06:01:17PM +0100, Krzysztof Kozlowski wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help