| Message ID | cover.1605226675.git.mirq-linux@rere.qmqm.pl (mailing list archive) |
|---|---|
| Headers | show |
| Series | regulator: debugging and fixing supply deps | expand |
Hello Michał, On 11/13/20 1:20 AM, Michał Mirosław wrote: > It turns out that commit aea6cb99703e ("regulator: resolve supply > after creating regulator") exposed a number of issues in regulator > initialization and introduced a memory leak of its own. One uncovered > problem was already fixed by cf1ad559a20d ("regulator: defer probe when > trying to get voltage from unresolved supply"). This series fixes the > remaining ones and adds a two debugging aids to help in the future. > > The final patch adds a workaround to preexisting problem occurring with > regulators that have the same name as its supply_name. This worked > before by accident, so might be worth backporting. The error message is > left on purpose so that these configurations can be detected and fixed. > > (The first two patches are resends from Nov 5). > > (Series resent because of wrong arm-kernel ML address.) lxa-mc1 (STM32MP1 board with STPMIC) now manages to boot again with following new warning: stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Supply for VREF_DDR So for the whole series, Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Thanks! Ahmad > > Michał Mirosław (4): > regulator: fix memory leak with repeated set_machine_constraints() > regulator: debug early supply resolving > regulator: avoid resolve_supply() infinite recursion > regulator: workaround self-referent regulators > > drivers/regulator/core.c | 40 ++++++++++++++++++++++++---------------- > 1 file changed, 24 insertions(+), 16 deletions(-) >
CC += linux-stm32 as other STM32MP1 boards are also affected. On 11/13/20 12:19 PM, Ahmad Fatoum wrote: > Hello Michał, > > On 11/13/20 1:20 AM, Michał Mirosław wrote: >> It turns out that commit aea6cb99703e ("regulator: resolve supply >> after creating regulator") exposed a number of issues in regulator >> initialization and introduced a memory leak of its own. One uncovered >> problem was already fixed by cf1ad559a20d ("regulator: defer probe when >> trying to get voltage from unresolved supply"). This series fixes the >> remaining ones and adds a two debugging aids to help in the future. >> >> The final patch adds a workaround to preexisting problem occurring with >> regulators that have the same name as its supply_name. This worked >> before by accident, so might be worth backporting. The error message is >> left on purpose so that these configurations can be detected and fixed. >> >> (The first two patches are resends from Nov 5). >> >> (Series resent because of wrong arm-kernel ML address.) > > lxa-mc1 (STM32MP1 board with STPMIC) now manages to boot again with following > new warning: > > stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Supply for VREF_DDR > > So for the whole series, > Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 > > Thanks! > Ahmad > >> >> Michał Mirosław (4): >> regulator: fix memory leak with repeated set_machine_constraints() >> regulator: debug early supply resolving >> regulator: avoid resolve_supply() infinite recursion >> regulator: workaround self-referent regulators >> >> drivers/regulator/core.c | 40 ++++++++++++++++++++++++---------------- >> 1 file changed, 24 insertions(+), 16 deletions(-) >> >
On Fri, 13 Nov 2020 01:20:26 +0100, Michał Mirosław wrote: > It turns out that commit aea6cb99703e ("regulator: resolve supply > after creating regulator") exposed a number of issues in regulator > initialization and introduced a memory leak of its own. One uncovered > problem was already fixed by cf1ad559a20d ("regulator: defer probe when > trying to get voltage from unresolved supply"). This series fixes the > remaining ones and adds a two debugging aids to help in the future. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/3] regulator: fix memory leak with repeated set_machine_constraints() commit: 57a6ad482af256b2a13de14194fb8f67c1a65f10 [2/3] regulator: avoid resolve_supply() infinite recursion commit: 4b639e254d3d4f15ee4ff2b890a447204cfbeea9 [3/3] regulator: workaround self-referent regulators commit: f5c042b23f7429e5c2ac987b01a31c69059a978b 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 Fri, 13 Nov 2020 01:20:26 +0100, Michał Mirosław wrote: > It turns out that commit aea6cb99703e ("regulator: resolve supply > after creating regulator") exposed a number of issues in regulator > initialization and introduced a memory leak of its own. One uncovered > problem was already fixed by cf1ad559a20d ("regulator: defer probe when > trying to get voltage from unresolved supply"). This series fixes the > remaining ones and adds a two debugging aids to help in the future. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/1] regulator: debug early supply resolving commit: 0917c9db23accb8690d8f1987ada36eb5b1a5ac9 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
It turns out that commit aea6cb99703e ("regulator: resolve supply after creating regulator") exposed a number of issues in regulator initialization and introduced a memory leak of its own. One uncovered problem was already fixed by cf1ad559a20d ("regulator: defer probe when trying to get voltage from unresolved supply"). This series fixes the remaining ones and adds a two debugging aids to help in the future. The final patch adds a workaround to preexisting problem occurring with regulators that have the same name as its supply_name. This worked before by accident, so might be worth backporting. The error message is left on purpose so that these configurations can be detected and fixed. (The first two patches are resends from Nov 5). (Series resent because of wrong arm-kernel ML address.) Michał Mirosław (4): regulator: fix memory leak with repeated set_machine_constraints() regulator: debug early supply resolving regulator: avoid resolve_supply() infinite recursion regulator: workaround self-referent regulators drivers/regulator/core.c | 40 ++++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 16 deletions(-)