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
