Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 05:24:55PM +0100, Mark Brown wrote:
>>> Cc-ing Mark in case he has any insights (I hope I have the right email
>>> address).
> But nobody who works on probe deferral or made any of the suggestions I
> mentioned in the message you linked to, nor anyone who works on the
> driver you've identified a bug in... :(
As for the former, I have no idea who they would be, sorry. For the latter,
isn't linux-samsung-soc@ the right place? MAINTAINERS said it was.
>> So fixing initramfs-tools to include the driver will seemingly fix (or maybe
>> more work around) the huge amounts of spam, but this is still a larger issue
>> that needs resolving.
> Not really, the issue you're seeing is just a plain resource leak in the
> driver that happens to blow up worse than normal in your particular
> configuration. This isn't even something related to probe deferral at
> the regulator level, the core is complaining that your system
> description is buggy as it has omitted some of the supplies for the
> device (notice how it says "using dummy regulator"...). This is
> happening a lot as the DWC3 driver is leaking, it is happening at all
> because when the Exynos DWC3 integration creates it PHYs it doesn't map
> the supplies through to them (it should be registering a supply alias to
> do this).
So there are multiple issues in play here. First of all, the leak is bad,
but it doesn't affect the issue with the system not booting. If I set
loglevel=0, it boots with or without the leak patch; however, it still sends
a gazillion error lines to dmesg (with or without the deferral).
Second, there's the issue that the driver takes so long to load in the first
place. This is because the regulator isn't up and doesn't come up before
after initramfs is done. This is a bug in Debian's initramfs-tools, but
hopefully easily remedied.
Then, there's the issue of why the messages come for each deferred probe
attempt. It seems from your message this is about something in the
declaration of the device tree; I don't understand the nuances here, but I
suppose it's pretty easy?
Fourth, there's the question of why there are thousands of probe attempts;
it shouldn't be even if the regulator takes a long time to come up. I guess
this is what your original message was about, and fixing that would also
reduce the amount of logging a ton (plus presumably speed up boot by wasting
less CPU on repeated probing). But as I understand you, it's not strictly
necessary to actually fix this issue?
Fifth and finally, there's the question of whether we can suppress
diagnostics on a probe that ends up being deferred. It would also solve the
problem here, although perhaps less elegantly than fixing issues #3 or
#4 (or to a lesser degree, #2), either of which will make my system boot. :-)
> The patch you linked to was for a completely different error message
> which is at least related to probe deferral
Yes, it's a different error message, but points to the same issue as #4
above, no?
> though fundamentally unless
> we just stop printing diagnostics (which is getting more and more
> tempting to be honest) I'm not sure anything is going to fully resolve
> leaks like this, the best chance you've got is something that explicitly
> looks at the dependencies like Raphael was proposing.
What do you mean by “leaks” here?
/* Steinar */
--
Homepage: https://www.sesse.net/
Reply to: