Thread (1 message) 1 message, 1 author, 2012-03-06

Re: obtaining a regulator from a phandle

From: Stephen Warren <hidden>
Date: 2012-03-06 17:21:40
Also in: linux-arm-kernel, linux-tegra

On 03/06/2012 04:39 AM, Thierry Reding wrote:
...
And this is precisely where things get ugly. Now there is a dependency
problem between the fixed regulator and the PMU which provides the GPIO. Both
the PMU and the fixed regulator are setup via subsys_initcall(), and the
regulator beats the PMU, resulting in the fixed regulator being unable to get
the GPIO because it hasn't been setup yet. So I remembered Grant's deferred
probing patch from yesterday and thought I'd try it out. This worked great,
and the fixed regulator was properly set up after all other devices had been
probed.
It's great that worked out.
The PCIe driver now also needs deferred probing until the fixed regulator is
present, which also works as expected. But then the problems start. Since now
we're so far into the boot process that all __init{,data} is gone, therefore
pci_common_init() is no longer present, resulting in an ugly crash.

So the only way I see out of this is patch up everything so that PCI
initialization can actually be done after init memory is freed. This would
have the added benefit that the driver could actually be built as a module.

Does anyone see another (easier) way out of this?
To me, that sounds like exactly how to solve it. You can probably mark
the code __devinit rather than just removing all the decorations
completely. You probably want to run this by the core ARM maintainers
though; I CC'd Russell and the ARM mailing list for comment.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help