| Message ID | E0925148-3F0E-4DD6-9872-96778BFE39DE@kohlschutter.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] regulator: core: Resolve supply name earlier to prevent double-init | expand |
On Fri, 22 Jul 2022 19:42:27 +0200, Christian Kohlschütter wrote: > Previously, an unresolved regulator supply reference upon calling > regulator_register on an always-on or boot-on regulator caused > set_machine_constraints to be called twice. > > This in turn may initialize the regulator twice, leading to voltage > glitches that are timing-dependent. A simple, unrelated configuration > change may be enough to hide this problem, only to be surfaced by > chance. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/1] regulator: core: Resolve supply name earlier to prevent double-init commit: 8a866d527ac0441c0eb14a991fa11358b476b11d 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 18. Aug 2022, at 17:22, Mark Brown <broonie@kernel.org> wrote: > > On Fri, 22 Jul 2022 19:42:27 +0200, Christian Kohlschütter wrote: >> Previously, an unresolved regulator supply reference upon calling >> regulator_register on an always-on or boot-on regulator caused >> set_machine_constraints to be called twice. >> >> This in turn may initialize the regulator twice, leading to voltage >> glitches that are timing-dependent. A simple, unrelated configuration >> change may be enough to hide this problem, only to be surfaced by >> chance. >> >> [...] > > Applied to > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next > > Thanks! > > [1/1] regulator: core: Resolve supply name earlier to prevent double-init > commit: 8a866d527ac0441c0eb14a991fa11358b476b11d > > 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 I've finally managed to publish a blog post about this journey into regulator land; I hope you find it worthwhile. https://kohlschuetter.github.io/blog/posts/2022/10/28/linux-nanopi-r4s/ Thanks to everybody involved for getting this far! Special thanks go to Robin Murphy for pulling out the oscillator, and Mark Brown for helping that these changes get into 6.1. Best, Christian
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 398c8d6afd4..5c2b97ea633 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5492,7 +5492,38 @@ regulator_register(const struct regulator_desc *regulator_desc, BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier); INIT_DELAYED_WORK(&rdev->disable_work, regulator_disable_work); - /* preform any regulator specific init */ + /* set regulator constraints */ + if (init_data) + rdev->constraints = kmemdup(&init_data->constraints, + sizeof(*rdev->constraints), + GFP_KERNEL); + else + rdev->constraints = kzalloc(sizeof(*rdev->constraints), + GFP_KERNEL); + if (!rdev->constraints) { + ret = -ENOMEM; + goto clean; + } + + if (init_data && init_data->supply_regulator) + rdev->supply_name = init_data->supply_regulator; + else if (regulator_desc->supply_name) + rdev->supply_name = regulator_desc->supply_name; + + if ((rdev->supply_name && !rdev->supply) && rdev->constraints + && (rdev->constraints->always_on || rdev->constraints->boot_on)) { + /* Try to resolve the name of the supplying regulator here first + * so we prevent double-initializing the regulator, which may + * cause timing-specific voltage brownouts/glitches that are + * hard to debug. + */ + ret = regulator_resolve_supply(rdev); + if (ret) + rdev_dbg(rdev, "unable to resolve supply early: %pe\n", + ERR_PTR(ret)); + } + + /* perform any regulator specific init */ if (init_data && init_data->regulator_init) { ret = init_data->regulator_init(rdev->reg_data); if (ret < 0) @@ -5518,24 +5549,6 @@ regulator_register(const struct regulator_desc *regulator_desc, (unsigned long) atomic_inc_return(®ulator_no)); dev_set_drvdata(&rdev->dev, rdev); - /* set regulator constraints */ - if (init_data) - rdev->constraints = kmemdup(&init_data->constraints, - sizeof(*rdev->constraints), - GFP_KERNEL); - else - rdev->constraints = kzalloc(sizeof(*rdev->constraints), - GFP_KERNEL); - if (!rdev->constraints) { - ret = -ENOMEM; - goto wash; - } - - if (init_data && init_data->supply_regulator) - rdev->supply_name = init_data->supply_regulator; - else if (regulator_desc->supply_name) - rdev->supply_name = regulator_desc->supply_name; - ret = set_machine_constraints(rdev); if (ret == -EPROBE_DEFER) { /* Regulator might be in bypass mode and so needs its supply
Previously, an unresolved regulator supply reference upon calling regulator_register on an always-on or boot-on regulator caused set_machine_constraints to be called twice. This in turn may initialize the regulator twice, leading to voltage glitches that are timing-dependent. A simple, unrelated configuration change may be enough to hide this problem, only to be surfaced by chance. One such example is the SD-Card voltage regulator in a NanoPI R4S that would not initialize reliably unless the registration flow was just complex enough to allow the regulator to properly reset between calls. Fix this by re-arranging regulator_register, trying resolve the regulator's supply early enough that set_machine_constraints does not need to be called twice. Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> --- drivers/regulator/core.c | 51 +++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 19 deletions(-)