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