BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Frank Wunderlich]

Hi,

i've encountered a bug in regulator between 5.3-rc5 and next-20190822

i build for bananapi-r2/mt7623 using this branch (includes next-patches):

https://github.com/vDorst/linux-1/blob/c34582d96520566c45068b92e080620458ffc1ff/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts#L166

and noticed that switch does not came up

priv->core_pwr = devm_regulator_get(&mdiodev->dev, "core"); returns 517

located here:
https://github.com/vDorst/linux-1/blob/c34582d96520566c45068b92e080620458ffc1ff/drivers/net/dsa/mt7530.c#L1590

#define EPROBE_DEFER 517/* Driver requests probe retry */

https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L1726

seems of_find_regulator_by_node(node); is failing here, but i see the dts-node (mt6323_vpa_reg: buck_vpa) in /sys/firmware/devicetree/...

tried without next-patches and switch came up including dsa-ports.

i found no commit yet which breaks the regulator-setup

any idea about this?

regards Frank

Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

On Thu, Aug 22, 2019 at 09:23:57PM +0200, Frank Wunderlich wrote:

> seems of_find_regulator_by_node(node); is failing here, but i see the dts-node (mt6323_vpa_reg: buck_vpa) in /sys/firmware/devicetree/...

It's not looking for the node in the device tree, it's looking
for that regulator to instantiate at runtime.  Is that happening?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Aw: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Frank Wunderlich]

cfba5de9b99f drivers: Introduce device lookup variants by of_node

this looks suspicios to me since the change is in the function which fails:

struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
 {
        struct device *dev;
 
-       dev = class_find_device(&regulator_class, NULL, np, of_node_match);
+       dev = class_find_device_by_of_node(&regulator_class, np);


but i cannot revert this commit so i did it manually...but this does not seem to be the cause...still error 517, also a change in core.c is not the cause...

how can i check instantiation at runtime?

regards Frank


> Gesendet: Donnerstag, 22. August 2019 um 21:30 Uhr
> Von: "Mark Brown" <broonie@kernel.org>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: "Liam Girdwood" <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, "René van Dorst" <opensource@vdorst.com>
> Betreff: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530
>
> On Thu, Aug 22, 2019 at 09:23:57PM +0200, Frank Wunderlich wrote:
> 
> > seems of_find_regulator_by_node(node); is failing here, but i see the dts-node (mt6323_vpa_reg: buck_vpa) in /sys/firmware/devicetree/...
> 
> It's not looking for the node in the device tree, it's looking
> for that regulator to instantiate at runtime.  Is that happening?
>

Re: Aw: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Thu, Aug 22, 2019 at 10:28:44PM +0200, Frank Wunderlich wrote:

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> cfba5de9b99f drivers: Introduce device lookup variants by of_node
> 
> this looks suspicios to me since the change is in the function which fails:

> struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
>  {
>         struct device *dev;
>  
> -       dev = class_find_device(&regulator_class, NULL, np, of_node_match);
> +       dev = class_find_device_by_of_node(&regulator_class, np);
> 
> 
> but i cannot revert this commit so i did it manually...but this does not seem to be the cause...still error 517, also a change in core.c is not the cause...

Can you run a git bisect to try to identify the commit that
caused things to fail?

> how can i check instantiation at runtime?

Look to see if there is a device driver bound to that device, or
check if the parent regulator is visible in /sys/class/regulators.  
You'll also see a mesage printed out for each regulator as it
instantiates in the boot logs, you can check there too.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Frank Wunderlich]

> Gesendet: Freitag, 23. August 2019 um 12:04 Uhr
> Von: "Mark Brown" <broonie@kernel.org>

> Can you run a git bisect to try to identify the commit that
> caused things to fail?

i have not figured out, how to rebase linux-next on my current (working) codebase :) (failes on file untouched by me at Patch 3/7000+)

> Look to see if there is a device driver bound to that device, or
> check if the parent regulator is visible in /sys/class/regulators.
> You'll also see a mesage printed out for each regulator as it
> instantiates in the boot logs, you can check there too.

in working version i only get this message in dmesg which
looks like a device-binding:

mt6323-regulator mt6323-regulator: Chip ID = 0x2023

this is my regulator: mt6323_vpa_reg

defined in arch/arm/boot/dts/mt6323.dtsi

&pwrap {
	pmic: mt6323 {
	  mt6323regulator: mt6323regulator{
		compatible = "mediatek,mt6323-regulator";
		mt6323_vpa_reg: buck_vpa{
			regulator-name = "vpa";
			regulator-min-microvolt = < 500000>;
			regulator-max-microvolt = <3650000>;
		};
	  };
	};
};

parent regulator is then
mt6323regulator: mt6323regulator

which is the one i see i dmesg.

in working version i see the regulator in sys-fs

cat /sys/class/regulator/regulator.*/name | grep vpa
vpa

-------------------------------------------------------------------

so, now to the non-working regulator:

dmesg do not have such entry ;(

regulators-list in /sys/class only containing the dummy and some fixed regulators

cat /sys/class/regulator/regulator.*/name
regulator-dummy
fixed-1.8V
fixed-3.3V
fixed-5V

in arch/arm/boot/dts/mt*.dts and Makefile there is no change between
working and non-working version.
in drivers/regulators only the 2 files where i had reverted the
changes manually without success.

where can be the cause for no more binding main-regulator?

are these strange messages related to this problem?

mtk-cpufreq mtk-cpufreq: failed to initialize dvfs info for cpu0

another strange line is this:

mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0

so the pwrap above regulator is affected too

and here are many changes in 2 files...

git diff --name-only non-working..working -- drivers/mfd/mt6397-*
drivers/mfd/mt6397-core.c
drivers/mfd/mt6397-irq.c

which brings me to this 2 commits:

a4872e80ce7d mfd: mt6397: Extract IRQ related code from core driver
708cb5cc3fde mfd: mt6397: Rename macros to something more readable

after reverting those 2 regulators are working again.
Adding both Signed-off-People to CC to keep them informed that a fix is needed

> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.

i currently write in webmailer, where i cannot set this setting,
i try to add manual linebreak in long lines, ok?

regards Frank

Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Matthias Brugger]

On 23/08/2019 14:00, Frank Wunderlich wrote:
>> Gesendet: Freitag, 23. August 2019 um 12:04 Uhr
>> Von: "Mark Brown" <broonie@kernel.org>
> 
>> Can you run a git bisect to try to identify the commit that
>> caused things to fail?
> 
> i have not figured out, how to rebase linux-next on my current (working) codebase :) (failes on file untouched by me at Patch 3/7000+)
> 
>> Look to see if there is a device driver bound to that device, or
>> check if the parent regulator is visible in /sys/class/regulators.
>> You'll also see a mesage printed out for each regulator as it
>> instantiates in the boot logs, you can check there too.
> 
> in working version i only get this message in dmesg which
> looks like a device-binding:
> 
> mt6323-regulator mt6323-regulator: Chip ID = 0x2023
> 
> this is my regulator: mt6323_vpa_reg
> 
> defined in arch/arm/boot/dts/mt6323.dtsi
> 
> &pwrap {
> 	pmic: mt6323 {
> 	  mt6323regulator: mt6323regulator{
> 		compatible = "mediatek,mt6323-regulator";
> 		mt6323_vpa_reg: buck_vpa{
> 			regulator-name = "vpa";
> 			regulator-min-microvolt = < 500000>;
> 			regulator-max-microvolt = <3650000>;
> 		};
> 	  };
> 	};
> };
> 
> parent regulator is then
> mt6323regulator: mt6323regulator
> 
> which is the one i see i dmesg.
> 
> in working version i see the regulator in sys-fs
> 
> cat /sys/class/regulator/regulator.*/name | grep vpa
> vpa
> 
> -------------------------------------------------------------------
> 
> so, now to the non-working regulator:
> 
> dmesg do not have such entry ;(
> 
> regulators-list in /sys/class only containing the dummy and some fixed regulators
> 
> cat /sys/class/regulator/regulator.*/name
> regulator-dummy
> fixed-1.8V
> fixed-3.3V
> fixed-5V
> 
> in arch/arm/boot/dts/mt*.dts and Makefile there is no change between
> working and non-working version.
> in drivers/regulators only the 2 files where i had reverted the
> changes manually without success.
> 
> where can be the cause for no more binding main-regulator?
> 
> are these strange messages related to this problem?
> 
> mtk-cpufreq mtk-cpufreq: failed to initialize dvfs info for cpu0
> 
> another strange line is this:
> 
> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0
> 
> so the pwrap above regulator is affected too
> 
> and here are many changes in 2 files...
> 
> git diff --name-only non-working..working -- drivers/mfd/mt6397-*
> drivers/mfd/mt6397-core.c
> drivers/mfd/mt6397-irq.c
> 
> which brings me to this 2 commits:
> 
> a4872e80ce7d mfd: mt6397: Extract IRQ related code from core driver
> 708cb5cc3fde mfd: mt6397: Rename macros to something more readable

These are commit IDs from linux-next. At least file from 20190822 should
pinpoint you to the correct commits.

@frank: please don't use commit IDs from linux-next as the history get's
rewritten every day and the IDs can change. Better search the tree to which they
got applied and use the commit IDs from there (stating, of course, which tree
you are looking at).

Looking at commit
a4872e80ce7d ("mfd: mt6397: Extract IRQ related code from core driver")

you can see that it doesn't just move the code but also adds new logic in
mt6397_irq_init(). :(

It seems your chip_id is not supported yet. So you will have to find out which
one it is and add it to the switch.

Hope that helped.
Matthias

> 
> after reverting those 2 regulators are working again.
> Adding both Signed-off-People to CC to keep them informed that a fix is needed
> 
>> Please fix your mail client to word wrap within paragraphs at something
>> substantially less than 80 columns.  Doing this makes your messages much
>> easier to read and reply to.
> 
> i currently write in webmailer, where i cannot set this setting,
> i try to add manual linebreak in long lines, ok?
> 
> regards Frank
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Frank Wunderlich]

Hi

Am 23. August 2019 16:43:47 MESZ schrieb Matthias Brugger <matthias.bgg@gmail.com>:
>On 23/08/2019 14:00, Frank Wunderlich wrote:
>> in working version i only get this message in dmesg which
>> looks like a device-binding:
>> 
>> mt6323-regulator mt6323-regulator: Chip ID = 0x2023

>> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0

>These are commit IDs from linux-next. At least file from 20190822
>should
>pinpoint you to the correct commits.
>
>@frank: please don't use commit IDs from linux-next as the history
>get's
>rewritten every day and the IDs can change. Better search the tree to
>which they
>got applied and use the commit IDs from there (stating, of course,
>which tree
>you are looking at).

Is there any easy way to get the right tree?

Can you give me an example bases on this commit? I thought adding the commit-subject is enough to find it also in a dynamic tree

>Looking at commit
>a4872e80ce7d ("mfd: mt6397: Extract IRQ related code from core driver")
>
>you can see that it doesn't just move the code but also adds new logic
>in
>mt6397_irq_init(). :(

I take a look at this function,thank you pointing to it

>It seems your chip_id is not supported yet. So you will have to find
>out which
>one it is and add it to the switch.

have posted it above ;) (0x2023)

Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

On Fri, Aug 23, 2019 at 02:00:16PM +0200, Frank Wunderlich wrote:
> > Gesendet: Freitag, 23. August 2019 um 12:04 Uhr
> > Von: "Mark Brown" <broonie@kernel.org>

> > Can you run a git bisect to try to identify the commit that
> > caused things to fail?
> 
> i have not figured out, how to rebase linux-next on my current (working) codebase :) (failes on file untouched by me at Patch 3/7000+)

git rebase --onto next/master <your base> is your best bet,
though it depends how long you've left it how easy that's going
to be.

> > Look to see if there is a device driver bound to that device, or
> > check if the parent regulator is visible in /sys/class/regulators.
> > You'll also see a mesage printed out for each regulator as it
> > instantiates in the boot logs, you can check there too.

> in working version i only get this message in dmesg which
> looks like a device-binding:

> mt6323-regulator mt6323-regulator: Chip ID = 0x2023

You shuould see announcements of the individual regulators on the
device from the regulator subsystem.

> 		mt6323_vpa_reg: buck_vpa{
> 			regulator-name = "vpa";
> 			regulator-min-microvolt = < 500000>;

In this case it'll say something about "vpa" if it registers this
one (but if there's a parent that's having trouble then this
won't register).

> parent regulator is then
> mt6323regulator: mt6323regulator

No, a parent regulator - something providing a power supply to
vpa.  Though I can't see anything in the kernel code that'd set
one up and there's nothing in the DT...

> where can be the cause for no more binding main-regulator?

You should generally get an error message if it's the regulator
subsystem.

> are these strange messages related to this problem?

> mtk-cpufreq mtk-cpufreq: failed to initialize dvfs info for cpu0

That's a user of the regulator so it's probably just a symptom of
the regulator not loading.

> another strange line is this:

> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0

This could well be it, if the MFD the device is on fails to load
the regulator won't either since it will only load after the MFD
does.  The MFD driver ensures that the drivers for all the
functions on the chip share the chip effectively.

> a4872e80ce7d mfd: mt6397: Extract IRQ related code from core driver
> 708cb5cc3fde mfd: mt6397: Rename macros to something more readable

> after reverting those 2 regulators are working again.
> Adding both Signed-off-People to CC to keep them informed that a fix is needed

That sounds like the issue then.

> > Please fix your mail client to word wrap within paragraphs at something
> > substantially less than 80 columns.  Doing this makes your messages much
> > easier to read and reply to.

> i currently write in webmailer, where i cannot set this setting,
> i try to add manual linebreak in long lines, ok?

Sure, thanks for trying.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]