* BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 @ 2019-08-22 19:23 Frank Wunderlich 2019-08-22 19:30 ` Mark Brown 0 siblings, 1 reply; 8+ messages in thread From: Frank Wunderlich @ 2019-08-22 19:23 UTC (permalink / raw) To: Liam Girdwood Cc: Mark Brown, linux-kernel, linux-mediatek, "René van Dorst" 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 2019-08-22 19:23 BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 Frank Wunderlich @ 2019-08-22 19:30 ` Mark Brown 2019-08-22 20:28 ` Aw: " Frank Wunderlich 0 siblings, 1 reply; 8+ messages in thread From: Mark Brown @ 2019-08-22 19:30 UTC (permalink / raw) To: Frank Wunderlich Cc: Liam Girdwood, linux-kernel, linux-mediatek, "René van Dorst" [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Aw: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 2019-08-22 19:30 ` Mark Brown @ 2019-08-22 20:28 ` Frank Wunderlich 2019-08-23 10:04 ` Mark Brown 0 siblings, 1 reply; 8+ messages in thread From: Frank Wunderlich @ 2019-08-22 20:28 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, linux-kernel, linux-mediatek, "René van Dorst" 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(®ulator_class, NULL, np, of_node_match); + dev = class_find_device_by_of_node(®ulator_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? > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Aw: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 2019-08-22 20:28 ` Aw: " Frank Wunderlich @ 2019-08-23 10:04 ` Mark Brown 2019-08-23 12:00 ` Aw: " Frank Wunderlich 0 siblings, 1 reply; 8+ messages in thread From: Mark Brown @ 2019-08-23 10:04 UTC (permalink / raw) To: Frank Wunderlich Cc: Liam Girdwood, linux-kernel, linux-mediatek, "René van Dorst" [-- 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(®ulator_class, NULL, np, of_node_match); > + dev = class_find_device_by_of_node(®ulator_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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 2019-08-23 10:04 ` Mark Brown @ 2019-08-23 12:00 ` Frank Wunderlich 2019-08-23 14:43 ` Matthias Brugger 2019-08-27 19:34 ` Mark Brown 0 siblings, 2 replies; 8+ messages in thread From: Frank Wunderlich @ 2019-08-23 12:00 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, linux-kernel, linux-mediatek, "René van Dorst", Hsin-Hsiung Wang, Lee Jones > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 2019-08-23 12:00 ` Aw: " Frank Wunderlich @ 2019-08-23 14:43 ` Matthias Brugger 2019-08-23 15:07 ` Frank Wunderlich 2019-08-27 19:34 ` Mark Brown 1 sibling, 1 reply; 8+ messages in thread From: Matthias Brugger @ 2019-08-23 14:43 UTC (permalink / raw) To: Frank Wunderlich, Mark Brown Cc: Liam Girdwood, linux-kernel, René van Dorst, linux-mediatek, Lee Jones, Hsin-Hsiung Wang 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 2019-08-23 14:43 ` Matthias Brugger @ 2019-08-23 15:07 ` Frank Wunderlich 0 siblings, 0 replies; 8+ messages in thread From: Frank Wunderlich @ 2019-08-23 15:07 UTC (permalink / raw) To: linux-mediatek, Matthias Brugger, Mark Brown Cc: Liam Girdwood, linux-kernel, René van Dorst, Lee Jones, Hsin-Hsiung Wang 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 2019-08-23 12:00 ` Aw: " Frank Wunderlich 2019-08-23 14:43 ` Matthias Brugger @ 2019-08-27 19:34 ` Mark Brown 1 sibling, 0 replies; 8+ messages in thread From: Mark Brown @ 2019-08-27 19:34 UTC (permalink / raw) To: Frank Wunderlich Cc: Liam Girdwood, linux-kernel, linux-mediatek, "René van Dorst", Hsin-Hsiung Wang, Lee Jones [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-27 19:35 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-22 19:23 BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530 Frank Wunderlich 2019-08-22 19:30 ` Mark Brown 2019-08-22 20:28 ` Aw: " Frank Wunderlich 2019-08-23 10:04 ` Mark Brown 2019-08-23 12:00 ` Aw: " Frank Wunderlich 2019-08-23 14:43 ` Matthias Brugger 2019-08-23 15:07 ` Frank Wunderlich 2019-08-27 19:34 ` Mark Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).