From: Andy Shevchenko <andy.shevchenko@gmail.com>
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
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework
Date: Sun, 11 Jul 2021 12:37:03 +0300 [thread overview]
Message-ID: <CAHp75VeugcuwWAq5p_rx+8J2FsX7igV+UJ3QKw3XG6BiDqTtNQ@mail.gmail.com> (raw)
In-Reply-To: <20210709170426.GC4112@sirena.org.uk>
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
next prev parent reply other threads:[~2021-07-11 9:37 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 22:42 [RFC PATCH 0/2] Add software node support to regulator framework Daniel Scally
2021-07-08 22:42 ` [RFC PATCH 1/2] regulator: Add support for software node connections Daniel Scally
2021-07-09 17:26 ` Mark Brown
2021-07-08 22:42 ` [RFC PATCH 2/2] platform/surface: Add Surface Go 2 board file Daniel Scally
2021-07-09 17:40 ` Mark Brown
2021-07-09 17:04 ` [RFC PATCH 0/2] Add software node support to regulator framework Mark Brown
2021-07-10 22:48 ` Daniel Scally
2021-07-12 14:15 ` Mark Brown
2021-07-12 16:55 ` Laurent Pinchart
2021-07-12 17:32 ` Mark Brown
2021-07-11 9:37 ` Andy Shevchenko [this message]
2021-07-12 12:42 ` Mark Brown
2021-07-12 13:01 ` Andy Shevchenko
2021-07-12 13:34 ` Mark Brown
2021-07-12 16:08 ` Andy Shevchenko
2021-07-12 17:01 ` Mark Brown
2021-07-12 23:32 ` Daniel Scally
2021-07-13 15:24 ` Mark Brown
2021-07-13 15:42 ` Laurent Pinchart
2021-07-13 16:02 ` Mark Brown
2021-07-13 16:06 ` Laurent Pinchart
2021-07-13 18:24 ` Mark Brown
2021-07-13 15:55 ` Andy Shevchenko
2021-07-13 18:18 ` Mark Brown
2021-07-13 19:46 ` Andy Shevchenko
2021-07-14 16:05 ` Mark Brown
2021-07-14 7:25 ` Laurent Pinchart
2021-07-14 16:59 ` Mark Brown
2021-07-14 17:18 ` Laurent Pinchart
2021-07-14 17:28 ` Mark Brown
2021-07-14 17:41 ` Laurent Pinchart
2021-07-14 19:18 ` Mark Brown
2021-07-14 21:53 ` Laurent Pinchart
2021-07-13 22:06 ` Daniel Scally
2021-07-10 22:28 ` Laurent Pinchart
2021-07-10 22:54 ` Daniel Scally
2021-07-11 16:55 ` Laurent Pinchart
2021-07-12 8:13 ` Daniel Scally
2021-07-12 11:50 ` Laurent Pinchart
2021-07-12 13:23 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHp75VeugcuwWAq5p_rx+8J2FsX7igV+UJ3QKw3XG6BiDqTtNQ@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=broonie@kernel.org \
--cc=djrscally@gmail.com \
--cc=hdegoede@redhat.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luzmaximilian@gmail.com \
--cc=mgross@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).