Re: [RFC PATCH 0/2] Add software node support to regulator framework

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
Date: Fri, 9 Jul 2021 18:04:26 +0100	[thread overview]
Message-ID: <20210709170426.GC4112@sirena.org.uk> (raw)
In-Reply-To: <20210708224226.457224-1-djrscally@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

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 ACPI
> firmware node. Those regulators have properties describing their constraints
> (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 same
> 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 allow the
> camera drivers to look up the correct regulator device. 

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 
> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]