Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 9 Jul 2021 18:04:26 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Daniel Scally <djrscally@gmail.com>
Cc:     linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org,
        hdegoede@redhat.com, mgross@linux.intel.com,
        luzmaximilian@gmail.com, lgirdwood@gmail.com,
        andy.shevchenko@gmail.com, laurent.pinchart@ideasonboard.com,
        kieran.bingham@ideasonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework
Message-ID: <20210709170426.GC4112@sirena.org.uk>
References: <20210708224226.457224-1-djrscally@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="E/DnYTRukya0zdZ1"
Content-Disposition: inline
In-Reply-To: <20210708224226.457224-1-djrscally@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--E/DnYTRukya0zdZ1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 08, 2021 at 11:42:24PM +0100, Daniel Scally wrote:

> See previous series for some background context [1]

That's a link to a series "[PATCH v5 0/6] Introduce intel_skl_int3472
module" which doesn't have any explanatory text as to what it's doing in
the cover letter (just an inter version changelog) nor any obvious
relevance to this series, are you sure that's the right link?  In
general it's best if your patch series contains enough explanatory
information to allow someone to have a reasonable idea what the series
does without having to follow links like this.

> This series is a prototype of an emulation of the device tree regulator
> initialisation and lookup functions, using software nodes. Software nodes

What is a software node and why would we want to use one here?

> relating to each regulator are registered as children of the TPS68470's A=
CPI
> firmware node. Those regulators have properties describing their constrai=
nts
> (for example "regulator-min-microvolt"). Similarly, software nodes are
> registered and assigned as secondary to the Camera's firmware node - these
> software nodes have reference properties named after the supply in the sa=
me
> way as device tree's phandles, for example "avdd-supply", and linking to =
the
> software node assigned to the appropriate regulator. We can then use those
> constraints to specify the appropriate voltages and the references to all=
ow the
> camera drivers to look up the correct regulator device.=20

So these systems lack an enumerable description of the system provided
by hardware or firmware (or given that these are ACPI systems I guess
the firmware description is just broken) so we need to use board files.
Why are we not just using board files, what does this new abstraction
solve?

> I'm posting this to see if people agree it's a good approach for tackling=
 the=20
> problem; I may be overthinking this and there's a much easier way that I =
should

I don't think I understand what the problem you are trying to solve is
so it's hard to say if this is a good approach to solving it.

--E/DnYTRukya0zdZ1
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDogZoACgkQJNaLcl1U
h9ANAQf+M9TONsSRsQlmFBCA2aVGotSOwxvK2eI+A5nP2zHCa4CxUR10Y1P80SvC
iPCQxqN2JO0E3jgcMgbXubCMN38zqMGKDVY1EQ9J4l8iChUdwshdGqjIRAy1Xtib
d2QWqJ2ucO6fjzPfFh5SB9nbPCI23nOipXuPmu7Cz3qWCGj3otBwPHSf51mLRdbV
vzO5L1KV2DAxcJ5vhP1TUZLWvOfbhgeAxYoLXrLdK/lchq0bcthknQt2Ml64b9CF
UgzbKV0hDjRKcUsatCD9VMqp5UBVIgjFzf9+pVN1Ad1pT5RZR/ZbMS2BThys5y5A
jsdef9OYk/m9QNn6TRIhW3dEtKSFXw==
=2klv
-----END PGP SIGNATURE-----

--E/DnYTRukya0zdZ1--