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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VeugcuwWAq5p_rx+8J2FsX7igV+UJ3QKw3XG6BiDqTtNQ@mail.gmail.com>
Date:   Sun, 11 Jul 2021 12:37:03 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Daniel Scally <djrscally@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        platform-driver-x86@...r.kernel.org, hdegoede@...hat.com,
        mgross@...ux.intel.com, luzmaximilian@...il.com,
        lgirdwood@...il.com, laurent.pinchart@...asonboard.com,
        kieran.bingham@...asonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework

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