[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgqIiv8fZeqFFUHX@sirena.org.uk>
Date: Mon, 14 Feb 2022 16:51:22 +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 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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists