Thread (70 messages) 70 messages, 15 authors, 2015-06-23

[PATCH 10/21] regulator: core: Probe regulators on demand

From: Tomeu Vizoso <hidden>
Date: 2015-05-26 17:53:58
Also in: lkml

On 26 May 2015 at 18:54, Mark Brown [off-list ref] wrote:
On Tue, May 26, 2015 at 05:08:38PM +0200, Tomeu Vizoso wrote:
quoted
On 26 May 2015 at 11:36, Mark Brown [off-list ref] wrote:
quoted
quoted
Yes, x86 based embedded systems use ACPI (and we really ought to be
trying to help systems using board files too for that matter).
quoted
Yes, I see how registering devices on-demand could be implemented for
all those, but what I don't see is how they would benefit from it.
You'd need to be clearer about what problem you're trying to solve
there, which is something you left us guessing at!
quoted
I can see an hypothetical maintenance benefit in sharing as much code
as possible between these different scenarios, but in this case,
because this feature is so closely tied to machine description I think
complexity would be actually bigger.
We've now got abstractions for common firmware operations (look at the
fwnode stuff) and this isn't exactly deep introspection here.

If you're trying to solve the probe order problem you can probably get a
long way by just doing something that boils down to "try to instantiate
everything referenced from this node" which could probably even be
kicked from the driver core prior to probe and cover most cases.  Or put
this into the node lookup interface so we try to instantiate everything
we reference.
quoted
On machines that have ACPI, most of those devices aren't exposed to
the kernel and few or no deferred probes happen (though I have only
tested on qemu and Minnowboard MAX, both with no deferred probes).
On the machines that you happen to have looked at; I would rather expect
that x86 based phones will be in a similar situation once they move to
ACPI which they should be doing this year if they didn't already, and
the embedded systems will doubtless run into this once they have any
meaningful hardware on them (the base Minnoboard isn't really
interesting here, it's once you build a system on top of that).
quoted
On machines with board files, devices are registered in a
predetermined order, presumably without any deferred probes.
No, not in the least.  Quite aside from anything else as soon as you
allow things to be built as modules userspace is free to load things in
whatever order amuses it.  Think about what's going on here - it's not
just registration of devices, it's also about the order in which
subsystems and drivers register themselves.
quoted
My understanding is that the problem I'm addressing is specific of
machines in which the kernel is in charge of pretty much everything
and that the information about what devices are present is given in an
arbitrary order.
I don't think you've fully understood the problem space here.
Fair enough, what's your understanding of it?

Thanks,

Tomeu
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help