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;
MIME-Version: 1.0
References: <20210708224226.457224-1-djrscally@gmail.com> <20210709170426.GC4112@sirena.org.uk>
In-Reply-To: <20210709170426.GC4112@sirena.org.uk>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Sun, 11 Jul 2021 12:37:03 +0300
Message-ID: <CAHp75VeugcuwWAq5p_rx+8J2FsX7igV+UJ3QKw3XG6BiDqTtNQ@mail.gmail.com>
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework
To:     Mark Brown <broonie@kernel.org>
Cc:     Daniel Scally <djrscally@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        platform-driver-x86@vger.kernel.org, hdegoede@redhat.com,
        mgross@linux.intel.com, luzmaximilian@gmail.com,
        lgirdwood@gmail.com, laurent.pinchart@ideasonboard.com,
        kieran.bingham@ideasonboard.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jul 9, 2021 at 8:05 PM Mark Brown <broonie@kernel.org> wrote:
> On Thu, Jul 08, 2021 at 11:42:24PM +0100, Daniel Scally wrote:

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

Software node is a representation of (missed and / or quirked)
firmware nodes in the code.

> Why are we not just using board files, what does this new abstraction
> solve?

Software node _is_ a board file part. The idea behind that is that the
driver, which requires any additional / necessary property that has
been missed in the firmware nodes, wouldn't need special treatment if
that property comes from a board file rather than firmware.

-- 
With Best Regards,
Andy Shevchenko

On Fri, Jul 9, 2021 at 8:05 PM Mark Brown <broonie@kernel.org> wrote:
>
> 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.


-- 
With Best Regards,
Andy Shevchenko