Messages in this thread | | | From | Saravana Kannan <> | Date | Sat, 18 Feb 2023 00:36:31 -0800 | Subject | Re: [RFC v1 0/4] Simplify regulator supply resolution code by offloading to driver core |
| |
On Sat, Feb 18, 2023 at 12:32 AM Saravana Kannan <saravanak@google.com> wrote: > > 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>
Christian, I was meaning to add you but I forgot. I'll add you to future versions.
-Saravana
> > 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 >
| |