On Thu, Sep 26, 2024 at 11:49 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Wed, 25 Sept 2024 at 11:38, Chen-Yu Tsai <wenst@xxxxxxxxxxxx> wrote: > > > > Hi folks, > > > > This series is split off from my "DT hardware prober" series [1]. > > > > Changes since v7: > > - Added stub versions for of_regulator_get_optional() for !CONFIG_OF > > and !CONFIG_REGULATOR > > - Added new patches for devres version and converting MTK pmdomain > > driver > > > > At ELCE, Sebastian told me about his recent work on adding regulator > > supply support to the Rockchip power domain driver [2], how the MediaTek > > driver has been using the existing devm_regulator_get() API and > > reassigning different device nodes to the device doing the lookup, and > > how the new of_regulator_get_optional() is the proper fit for this. > > > > Patch 1 adds a new of_regulator_get_optional() function to look up > > regulator supplies using device tree nodes. > > > > Patch 2 adds a devres version of the aforementioned function at > > Sebastian's request for the two power domain drivers. > > > > Patch 3 converts the MediaTek power domain driver to use function. > > > > > > Each of the latter two patches depend on the previous one at build time. > > Mark, would it be possible for you to put the two regulator patches > > on an immutable branch / tag? Otherwise we could have Ulf ack the > > pmdomain patch and merge it through your tree. Sebastian was fine > > with converting the rockchip pmdomain some time later. > > Thanks for providing some context! > > In my opinion I would prefer an immutable branch/tag of the regulator > core changes, so I can carry the pmdomain changes for MTK through my > pmdomain tree, but also because I would prefer if Sebastian could make > the corresponding conversion for the Rockchip pmdomain driver. If this > can get queued soon, there is really no need to have an intermediate > step for Rockchip, I think. > > Does it make sense - or do you prefer another way forward? Makes sense to me! ChenYu
