I found a use_count leakage towards supply regulator of rdev with
boot-on option.

┌───────────────────┐           ┌───────────────────┐
│  regulator_dev A  │           │  regulator_dev B  │
│     (boot-on)     │           │     (boot-on)     │
│    use_count=0    │◀──supply──│    use_count=1    │
│                   │           │                   │
└───────────────────┘           └───────────────────┘

In case of rdev(A) configured with `regulator-boot-on', the use_count
of supplying regulator(B) will increment inside
regulator_enable(rdev->supply).

Thus, B will acts like always-on, and further balanced
regulator_enable/disable cannot actually disable it anymore.

However, B was also configured with `regulator-boot-on', we wish it
could be disabled afterwards.

Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
---
 drivers/regulator/core.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e8c00a884f1f..1cfac32121c0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1596,7 +1596,13 @@ static int set_machine_constraints(struct regulator_dev *rdev)
                if (rdev->supply_name && !rdev->supply)
                        return -EPROBE_DEFER;

-               if (rdev->supply) {
+               /* If supplying regulator has already been enabled,
+                * it's not intended to have use_count increment
+                * when rdev is only boot-on.
+                */
+               if (rdev->supply &&
+                   (rdev->constraints->always_on ||
+                    !regulator_is_enabled(rdev->supply))) {
                        ret = regulator_enable(rdev->supply);
                        if (ret < 0) {
                                _regulator_put(rdev->supply);
--
2.34.1

________________________________

本邮件及其附件内容可能含有机密和/或隐私信息，仅供指定个人或机构使用。若您非发件人指定收件人或其代理人，请勿使用、传播、复制或存储此邮件之任何内容或其附件。如您误收本邮件，请即以回复或电话方式通知发件人，并将原始邮件、附件及其所有复本删除。谢谢。
The contents of this message and any attachments may contain confidential and/or privileged information and are intended exclusively for the addressee(s). If you are not the intended recipient of this message or their agent, please note that any use, dissemination, copying, or storage of this message or its attachments is not allowed. If you receive this message in error, please notify the sender by reply the message or phone and delete this message, any attachments and any copies immediately.
Thank you

On Tue, 22 Nov 2022 18:32:51 +0800, Rui Zhang wrote:
> I found a use_count leakage towards supply regulator of rdev with
> boot-on option.
> 
> ┌───────────────────┐           ┌───────────────────┐
> │  regulator_dev A  │           │  regulator_dev B  │
> │     (boot-on)     │           │     (boot-on)     │
> │    use_count=0    │◀──supply──│    use_count=1    │
> │                   │           │                   │
> └───────────────────┘           └───────────────────┘
> 
> [...]

Applied to

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

Thanks!

[1/1] regulator: core: fix use_count leakage when handling boot-on
      commit: 0591b14ce0398125439c759f889647369aa616a0

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

On Tue, Nov 22, 2022 at 06:32:51PM +0800, Rui Zhang wrote:
> I found a use_count leakage towards supply regulator of rdev with
> boot-on option.

This doesn't apply against current code, please check and resend.