Message-Id: <20230218083252.2044423-1-saravanak@google.com>
Date:   Sat, 18 Feb 2023 00:32:47 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>
Cc:     Saravana Kannan <saravanak@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Tony Lindgren <tony@...mide.com>,
        Doug Anderson <dianders@...omium.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Luca Weiss <luca.weiss@...rphone.com>, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org
Subject: [RFC v1 0/4] Simplify regulator supply resolution code by offloading
 to driver core

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@...uxfoundation.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Bjorn Andersson <andersson@...nel.org>
Cc: Sudeep Holla <sudeep.holla@....com>
Cc: Tony Lindgren <tony@...mide.com>
Cc: Doug Anderson <dianders@...omium.org>
Cc: Guenter Roeck <linux@...ck-us.net>
Cc: Luca Weiss <luca.weiss@...rphone.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

Powered by blists - more mailing lists