From: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> To: Ahmad Fatoum <a.fatoum@pengutronix.de> Cc: Corentin Labbe <clabbe.montjoie@gmail.com>, lgirdwood@gmail.com, mripard@kernel.org, linux-kernel@vger.kernel.org, wens@csie.org, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, "linux-stm32@st-md-mailman.stormreply.com" <linux-stm32@st-md-mailman.stormreply.com>, Pengutronix Kernel Team <kernel@pengutronix.de> Subject: Re: [BUG] Error applying setting, reverse things back on lot of devices Date: Sun, 8 Nov 2020 18:08:07 +0100 [thread overview] Message-ID: <20201108170807.GA10914@qmqm.qmqm.pl> (raw) In-Reply-To: <7edc2b69-b77b-3546-63d7-108dab95fc91@pengutronix.de> On Thu, Nov 05, 2020 at 10:11:30AM +0100, Ahmad Fatoum wrote: > Hello, > > On 11/5/20 3:57 AM, Michał Mirosław wrote: > >>> Can you catch debug logs for the bootup in question? I'm not sure what's > >>> the failure mode in your case. I guess this is not a bypassed regulator? > >> > >> Boot up with v5.10-rc2 + your cf1ad559a2 ("regulator: defer probe when trying > >> to get voltage from unresolved supply") hangs: > >> > >> [ 1.151489] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter > >> [ 1.180698] stpmic1 1-0033: PMIC Chip Version: 0x10 > >> [ 1.189526] vddcore: supplied by regulator-dummy > >> [ 1.195633] vdd_ddr: supplied by regulator-dummy > >> [ 1.201672] vdd: supplied by regulator-dummy > >> [ 1.207452] v3v3: supplied by 5V2 > >> [ 1.211997] v1v8_audio: supplied by v3v3 > >> [ 1.218036] v3v3_hdmi: supplied by 5V2 > >> [ 1.223626] vtt_ddr: supplied by regulator-dummy > >> [ 1.227107] vdd_usb: supplied by regulator-dummy > >> [ 1.234532] vdda: supplied by 5V2 > >> [ 1.239497] v1v2_hdmi: supplied by v3v3 > > [...] > > > > Can you try with the patches I just sent and with debug logs enabled? > > > > The first one just plugs a memory leak, but if there is some state > > changed/saved in the rdev->constraints (can't find that code, though), > > this might prevent it from being overwritten. > > > > The second patch will just tell us if you hit the early resolve case. > > Problem still persists. Early resolve case not hit: [...] > [ 1.594492] vref_ddr: at 500 mV, enabled > [ 1.597047] edt_ft5x06 0-0038: touchscreen probe failed > [ 1.597211] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply from device tree > [ 1.612406] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed > > [ snip - continues many times ] > > [ 6.699244] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed > [ 6.713312] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply from device tree It seems that final regulator_resolve_supply() is spinning recursively. Is the regulator name the same as its supply_name? Can you try the patch below to verify this? Best Regards Michał Mirosław diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index c84e3b0b63de..983a4bd3e98c 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1798,6 +1798,8 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) if (rdev->supply) return 0; + dev_dbg(dev, "Resolving supply %s for %s\n", rdev->supply_name, rdev->desc->name); + r = regulator_dev_lookup(dev, rdev->supply_name); if (IS_ERR(r)) { ret = PTR_ERR(r); @@ -1816,6 +1818,12 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) } } + if (r == rdev) { + dev_err(dev, "Supply for %s (%s) resolved to itself\n", + rdev->desc->name, rdev->supply_name); + return -EINVAL; + } + /* * If the supply's parent device is not the same as the * regulator's parent device, then ensure the parent device
WARNING: multiple messages have this Message-ID (diff)
From: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> To: Ahmad Fatoum <a.fatoum@pengutronix.de> Cc: lgirdwood@gmail.com, mripard@kernel.org, linux-kernel@vger.kernel.org, wens@csie.org, broonie@kernel.org, Corentin Labbe <clabbe.montjoie@gmail.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, "linux-stm32@st-md-mailman.stormreply.com" <linux-stm32@st-md-mailman.stormreply.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [BUG] Error applying setting, reverse things back on lot of devices Date: Sun, 8 Nov 2020 18:08:07 +0100 [thread overview] Message-ID: <20201108170807.GA10914@qmqm.qmqm.pl> (raw) In-Reply-To: <7edc2b69-b77b-3546-63d7-108dab95fc91@pengutronix.de> On Thu, Nov 05, 2020 at 10:11:30AM +0100, Ahmad Fatoum wrote: > Hello, > > On 11/5/20 3:57 AM, Michał Mirosław wrote: > >>> Can you catch debug logs for the bootup in question? I'm not sure what's > >>> the failure mode in your case. I guess this is not a bypassed regulator? > >> > >> Boot up with v5.10-rc2 + your cf1ad559a2 ("regulator: defer probe when trying > >> to get voltage from unresolved supply") hangs: > >> > >> [ 1.151489] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter > >> [ 1.180698] stpmic1 1-0033: PMIC Chip Version: 0x10 > >> [ 1.189526] vddcore: supplied by regulator-dummy > >> [ 1.195633] vdd_ddr: supplied by regulator-dummy > >> [ 1.201672] vdd: supplied by regulator-dummy > >> [ 1.207452] v3v3: supplied by 5V2 > >> [ 1.211997] v1v8_audio: supplied by v3v3 > >> [ 1.218036] v3v3_hdmi: supplied by 5V2 > >> [ 1.223626] vtt_ddr: supplied by regulator-dummy > >> [ 1.227107] vdd_usb: supplied by regulator-dummy > >> [ 1.234532] vdda: supplied by 5V2 > >> [ 1.239497] v1v2_hdmi: supplied by v3v3 > > [...] > > > > Can you try with the patches I just sent and with debug logs enabled? > > > > The first one just plugs a memory leak, but if there is some state > > changed/saved in the rdev->constraints (can't find that code, though), > > this might prevent it from being overwritten. > > > > The second patch will just tell us if you hit the early resolve case. > > Problem still persists. Early resolve case not hit: [...] > [ 1.594492] vref_ddr: at 500 mV, enabled > [ 1.597047] edt_ft5x06 0-0038: touchscreen probe failed > [ 1.597211] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply from device tree > [ 1.612406] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed > > [ snip - continues many times ] > > [ 6.699244] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed > [ 6.713312] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply from device tree It seems that final regulator_resolve_supply() is spinning recursively. Is the regulator name the same as its supply_name? Can you try the patch below to verify this? Best Regards Michał Mirosław diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index c84e3b0b63de..983a4bd3e98c 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1798,6 +1798,8 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) if (rdev->supply) return 0; + dev_dbg(dev, "Resolving supply %s for %s\n", rdev->supply_name, rdev->desc->name); + r = regulator_dev_lookup(dev, rdev->supply_name); if (IS_ERR(r)) { ret = PTR_ERR(r); @@ -1816,6 +1818,12 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) } } + if (r == rdev) { + dev_err(dev, "Supply for %s (%s) resolved to itself\n", + rdev->desc->name, rdev->supply_name); + return -EINVAL; + } + /* * If the supply's parent device is not the same as the * regulator's parent device, then ensure the parent device _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-08 17:08 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-21 18:31 [BUG] Error applying setting, reverse things back on lot of devices Corentin Labbe 2020-10-21 18:31 ` Corentin Labbe 2020-10-23 13:42 ` Corentin Labbe 2020-10-23 13:42 ` Corentin Labbe 2020-10-23 20:39 ` Corentin Labbe 2020-10-23 20:39 ` Corentin Labbe 2020-10-24 11:40 ` Michał Miosław 2020-10-24 11:40 ` Michał Miosław 2020-10-24 11:53 ` Michał Mirosław 2020-10-24 11:53 ` Michał Mirosław 2020-11-01 1:31 ` Ondřej Jirman 2020-11-01 1:31 ` Ondřej Jirman 2020-11-02 7:40 ` Corentin Labbe 2020-11-02 7:40 ` Corentin Labbe 2020-11-02 12:48 ` Ahmad Fatoum 2020-11-02 12:48 ` Ahmad Fatoum 2020-11-02 20:27 ` Michał Mirosław 2020-11-02 20:27 ` Michał Mirosław 2020-11-04 10:28 ` Ahmad Fatoum 2020-11-04 10:28 ` Ahmad Fatoum 2020-11-04 10:50 ` [Linux-stm32] " Alexandre Torgue 2020-11-04 10:50 ` Alexandre Torgue 2020-11-05 8:47 ` Ahmad Fatoum 2020-11-05 8:47 ` Ahmad Fatoum 2020-11-05 2:57 ` Michał Mirosław 2020-11-05 2:57 ` Michał Mirosław 2020-11-05 9:11 ` Ahmad Fatoum 2020-11-05 9:11 ` Ahmad Fatoum 2020-11-08 17:08 ` Michał Mirosław [this message] 2020-11-08 17:08 ` Michał Mirosław 2020-11-10 10:57 ` Ahmad Fatoum 2020-11-10 10:57 ` Ahmad Fatoum
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201108170807.GA10914@qmqm.qmqm.pl \ --to=mirq-linux@rere.qmqm.pl \ --cc=a.fatoum@pengutronix.de \ --cc=broonie@kernel.org \ --cc=clabbe.montjoie@gmail.com \ --cc=kernel@pengutronix.de \ --cc=lgirdwood@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=mripard@kernel.org \ --cc=wens@csie.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.