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 for Android: free password hash cracker in your pocket

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

Message-ID: <20210709170426.GC4112@sirena.org.uk>
Date:   Fri, 9 Jul 2021 18:04:26 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Daniel Scally <djrscally@...il.com>
Cc:     linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        hdegoede@...hat.com, mgross@...ux.intel.com,
        luzmaximilian@...il.com, lgirdwood@...il.com,
        andy.shevchenko@...il.com, laurent.pinchart@...asonboard.com,
        kieran.bingham@...asonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)