Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 10 Jun 2022 12:03:41 +0100
From:   Mark Brown <broonie@kernel.org>
To:     ChiYuan Huang <u0084500@gmail.com>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Lee Jones <lee.jones@linaro.org>, dmitry.torokhov@gmail.com,
        Liam Girdwood <lgirdwood@gmail.com>,
        cy_huang <cy_huang@richtek.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>,
        linux-input@vger.kernel.org
Subject: Re: [PATCH 3/4] regulator: rt5120: Add PMIC regulator support
Message-ID: <YqMlDVMlukNAns5S@sirena.org.uk>
References: <1654581161-12349-1-git-send-email-u0084500@gmail.com>
 <1654581161-12349-4-git-send-email-u0084500@gmail.com>
 <Yp+gS6r5Kpi33Ags@sirena.org.uk>
 <CADiBU38+0vp3Dv6i7uYzCwR431PKBr-HNQnY0Qe7fvvRYGEJmw@mail.gmail.com>
 <YqB19O/HYvEAxdiM@sirena.org.uk>
 <CADiBU390XRXZ2yx5CT2NxhN3aROHXcxs7w2d-xhB6+EYn+uTfA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="9eWHlLQ5aB+zBDiA"
Content-Disposition: inline
In-Reply-To: <CADiBU390XRXZ2yx5CT2NxhN3aROHXcxs7w2d-xhB6+EYn+uTfA@mail.gmail.com>
Precedence: bulk


--9eWHlLQ5aB+zBDiA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 09, 2022 at 02:35:07PM +0800, ChiYuan Huang wrote:
> Mark Brown <broonie@kernel.org> =E6=96=BC 2022=E5=B9=B46=E6=9C=888=E6=97=
=A5 =E9=80=B1=E4=B8=89 =E4=B8=8B=E5=8D=886:12=E5=AF=AB=E9=81=93=EF=BC=9A
> > On Wed, Jun 08, 2022 at 11:15:56AM +0800, ChiYuan Huang wrote:

> > > My excuse. let me explain it.
> > > buck1 voltage range from 600mV to 1393.75mV.
> > > buck2~4/ldo/exten is the fixed regulator.
> > > buck3 and buck4 is fixed by the IC efuse default.
> > > buck2 and ldo is fixed by the external resistor chosen.
> > > exten is designed to connected to the external power.

> > > That's why I cannot directly declared it as the static regulator_desc.

> > So buck 2-4 need some dynamic handling then but the rest can be static -
> > that would be a lot clearer.  You could also have a template for the
> > ones with some dynamic values and just override the few fields that need
> > it.

> Not just buck2/3, buck2/3/4/ldo/exten all need the dynamic handling.

Why do the others need it?

> > > > Drivers should never override constraints passed in by machine driv=
ers,
> > > > if there's validation needed let the core do it.  The same probably
> > > > applies to providing a voltage range for a fixed regulator though t=
hat's
> > > > not modifying everything so not such a problem.

> > > Please check the above explanation about each power rails.

> > I'm not sure what you're referencing here?

> Sorry. Let me explain it.

> You mean 'of_parse_cb' must not override constraint.
> But if the regulator is fixed and dynamic, after
> 'of_get_regulation_constraint', apply_uV will be true.
> The is referring to 'fixed.c'

fixed.c is a special case due to legacy issues and being generic, for
normal fixed voltage regulators in a device where we know what they're
fixed to they can just have their voltage hard coded in the driver.  If
there's issues with the machine providing invalid or nonsensical
constraints the driver should just let the core deal with them.

> > > > This is all open coding stuff that's in the core - just provde an
> > > > of_parse_cb() operation and let the core take care of calling it.

> > > Ditto

> > Or here.

> If I put 'of_parce_cb' to make core handling it, the input parameter
> 'init_data' is declared as const.
> I cannot override the 'apply_uV'.
> Right?

Yes, that's by design.

--9eWHlLQ5aB+zBDiA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmKjJQwACgkQJNaLcl1U
h9BwbQf8CDon0DOTyygjzDQP19A8QQ9eIkDydN4RwUztGzO1oZZqgyPddsborEnm
enToWNLNXMvBEUM6ybjKDOi4Ac5UxHfxPW5tci2AOWfX6/LREJFiQR/ekmLPhgj9
Cizn5N/0HstZFFm5g/lfsEYtxyCtVdd6StaeLXsGI2LD282RMqLhuyuq+1gmmv4v
AOVc1KfT3CWAsiA1yYGY8TOugdKahJmuNAmAE9kH/JduhtPJMSG0jwhrlY9zHr46
m/9ePyvPYkStQ28gQEgogcC6kUGHL/gZ9aEy/wCpKAUNtXw49bFDgImT1bmiVE3O
vtsKqJOL7LmZ2pIyfeIKDPPiBJAUAQ==
=xKE/
-----END PGP SIGNATURE-----

--9eWHlLQ5aB+zBDiA--