Messages in this thread | | | From | Andy Shevchenko <> | Date | Sun, 11 Jul 2021 12:37:03 +0300 | 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@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
| |