[PATCH 0/2] Allow mtk-regulator-coupler to be built as a module

Justin Yeh posted 2 patches 3 weeks, 2 days ago
drivers/regulator/core.c     | 4 ++++
drivers/soc/mediatek/Kconfig | 6 +++++-
2 files changed, 9 insertions(+), 1 deletion(-)
[PATCH 0/2] Allow mtk-regulator-coupler to be built as a module
Posted by Justin Yeh 3 weeks, 2 days ago
MTK_REGULATOR_COUPLER can currently only be built into the kernel: it is
a bool, and its prompt is hidden unless COMPILE_TEST is set, so on real
MediaTek configurations the symbol has no prompt and is forced to its
"default ARCH_MEDIATEK" value.

Kernels that ship nearly everything as a module (Android GKI style
kernels, but distro kernels have the same shape) cannot use it that way.
Two things are in the way:

  - the four helpers the coupler calls are declared in
    include/linux/regulator/coupler.h for coupler implementations to
    use, but none of them is exported (patch 1);

  - the Kconfig symbol is a bool without a usable prompt (patch 2).

With both patches applied, CONFIG_MTK_REGULATOR_COUPLER=m builds and
mtk_regulator_coupler.ko loads and registers the coupler. Existing
configurations are unaffected: "default ARCH_MEDIATEK" is kept, so they
keep building the coupler in.

Justin Yeh (2):
  regulator: core: Export helpers used by regulator couplers
  soc: mediatek: mtk-regulator-coupler: Allow building as a module

 drivers/regulator/core.c     | 4 ++++
 drivers/soc/mediatek/Kconfig | 6 +++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.45.2
Re: [PATCH 0/2] Allow mtk-regulator-coupler to be built as a module
Posted by Mark Brown 9 hours ago
On Thu, Sep 03, 2026 at 02:20:45PM +0800, Justin Yeh wrote:
> MTK_REGULATOR_COUPLER can currently only be built into the kernel: it is
> a bool, and its prompt is hidden unless COMPILE_TEST is set, so on real
> MediaTek configurations the symbol has no prompt and is forced to its
> "default ARCH_MEDIATEK" value.

The following changes since commit 940de590b839f71d6dc846160534bf202401b8b7:

  Merge tag 'hardening-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2026-09-02 16:02:02 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-export-coupling-api

for you to fetch changes up to 59951bd9c6b63d4d98539db96becef729ad60b4a:

  regulator: core: Export helpers used by regulator couplers (2026-09-25 18:44:46 +0100)

----------------------------------------------------------------
regulator: core: Export helpers used by regulator couplers

regulator_check_voltage(), regulator_check_consumers(),
regulator_do_balance_voltage() and regulator_coupler_register() are
already declared in include/linux/regulator/coupler.h for regulator
coupler implementations to use, but none of them is exported. That
limits couplers to being built into the kernel.

Export them so that coupler drivers can be built as loadable modules.

----------------------------------------------------------------
Justin Yeh (1):
      regulator: core: Export helpers used by regulator couplers

 drivers/regulator/core.c | 4 ++++
 1 file changed, 4 insertions(+)
Re: [PATCH 0/2] Allow mtk-regulator-coupler to be built as a module
Posted by Justin Yeh 1 week, 1 day ago
Hi Mark, Liam, Matthias, Angelo,

Gentle ping on this series, sent two weeks ago:
https://lore.kernel.org/all/20260903062056.1024263-1-justin.yeh@mediatek.com/

Is it OK to pick up as it is, or is there something you would like me to
change first?

One note on the routing: patch 2/2 (soc/mediatek Kconfig) depends on the
exports added by patch 1/2 (regulator core), so the two have to land in
that order - ideally via the same tree.

Thanks,
Justin
Re: [PATCH 0/2] Allow mtk-regulator-coupler to be built as a module
Posted by Mark Brown 1 week ago
On Fri, Sep 18, 2026 at 08:37:22AM +0800, Justin Yeh wrote:
> Hi Mark, Liam, Matthias, Angelo,
> 
> Gentle ping on this series, sent two weeks ago:
> https://lore.kernel.org/all/20260903062056.1024263-1-justin.yeh@mediatek.com/

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
Re: (subset) [PATCH 0/2] Allow mtk-regulator-coupler to be built as a module
Posted by Mark Brown 14 hours ago
On Thu, 03 Sep 2026 14:20:45 +0800, Justin Yeh wrote:
> Allow mtk-regulator-coupler to be built as a module
> 
> MTK_REGULATOR_COUPLER can currently only be built into the kernel: it is
> a bool, and its prompt is hidden unless COMPILE_TEST is set, so on real
> MediaTek configurations the symbol has no prompt and is forced to its
> "default ARCH_MEDIATEK" value.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.4

Thanks!

[1/2] regulator: core: Export helpers used by regulator couplers
      https://git.kernel.org/broonie/regulator/c/59951bd9c6b6

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark