mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>
Cc: Saravana Kannan <saravanak@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Tony Lindgren <tony@atomide.com>,
	Doug Anderson <dianders@chromium.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Luca Weiss <luca.weiss@fairphone.com>,
	kernel-team@android.com, linux-kernel@vger.kernel.org
Subject: [RFC v1 0/4] Simplify regulator supply resolution code by offloading to driver core
Date: Sat, 18 Feb 2023 00:32:47 -0800	[thread overview]
Message-ID: <20230218083252.2044423-1-saravanak@google.com> (raw)

Hi Mark/Liam,

This series is just an RFC to see if you agree with where this is going.
Please point out bugs, but don't bother with a proper code review.

The high level idea is to not reimplement what driver core can already
handle for us and use it to do some of the work. Instead of trying to
resolve supplies from all different code paths and bits and pieces of
the tree, we just build it from the root to the leaves by using deferred
probing to sequence things in the right order.

The last patch is the main one. Rest of them are just setting up for it.

I believe there's room for further simplification but this is what I
could whip up as a quick first draft that shows the high level idea.
I'll probably need some help with getting a better understanding of why
things are done in a specific order in regulator_register() before I
could attempt simplifying things further.

Ideally, regulator_register() would just have DT parsing, init data
struct sanity checks and adding the regulator device and then we move
everything else to into the probe function that's guaranteed to run only
after the supply has been resolved/ready to resolve.

fw_devlink/device links should further optimize the flow and also allow
us to simplify some of the guarantees and address some of the existing
FIXMEs. But this patch series is NOT dependent on fw_devlink or device
links.

Any thoughts on where this is going?

I've tested this on one hardware I have and it works and nothing is
broken. But the regulator tree in my hardware isn't that complicated or
deep. The regulators are also added mostly in the right order (due to
existing fw_devlink). So if you agree with the idea, the next step is to
ask people to give it a test.

Also, it's based on driver-core-next since that's what I had synced up
and had a working baseline. I'll rebase it on the regulator tree when I
go from RFC -> PATCH.

Thanks,
Saravana

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Luca Weiss <luca.weiss@fairphone.com>

Saravana Kannan (4):
  regulator: core: Add regulator devices to bus instead of class
  regulator: core: Add sysfs class backward compatibility
  regulator: core: Probe regulator devices
  regulator: core: Move regulator supply resolving to the probe function

 drivers/regulator/core.c         | 102 +++++++++++++++++++------------
 drivers/regulator/internal.h     |   2 +-
 drivers/regulator/of_regulator.c |   2 +-
 3 files changed, 64 insertions(+), 42 deletions(-)

-- 
2.39.2.637.g21b0678d19-goog


             reply	other threads:[~2023-02-18  8:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230218083300eucas1p28c7c584877b8914a3b88904690be82f6@eucas1p2.samsung.com>
2023-02-18  8:32 ` Saravana Kannan [this message]
2023-02-18  8:32   ` [RFC v1 1/4] regulator: core: Add regulator devices to bus instead of class Saravana Kannan
2023-02-18  8:32   ` [RFC v1 2/4] regulator: core: Add sysfs class backward compatibility Saravana Kannan
2023-02-22 17:47     ` Mark Brown
2023-02-18  8:32   ` [RFC v1 3/4] regulator: core: Probe regulator devices Saravana Kannan
2023-02-22 17:50     ` Mark Brown
2023-02-18  8:32   ` [RFC v1 4/4] regulator: core: Move regulator supply resolving to the probe function Saravana Kannan
2023-02-22 22:51     ` Mark Brown
2023-02-18  8:36   ` [RFC v1 0/4] Simplify regulator supply resolution code by offloading to driver core Saravana Kannan
2023-02-18  8:54   ` Greg Kroah-Hartman
2023-02-20  9:01   ` Marek Szyprowski
2023-02-21 22:36     ` Saravana Kannan
2023-02-21 22:52       ` Mark Brown
2023-02-22  3:13         ` Saravana Kannan
2023-02-22 14:54           ` Mark Brown
2023-02-22  7:15       ` Marek Szyprowski

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=20230218083252.2044423-1-saravanak@google.com \
    --to=saravanak@google.com \
    --cc=andersson@kernel.org \
    --cc=broonie@kernel.org \
    --cc=dianders@chromium.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luca.weiss@fairphone.com \
    --cc=m.szyprowski@samsung.com \
    --cc=sudeep.holla@arm.com \
    --cc=tony@atomide.com \
    /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

all inboxes | Powered by JetHome®