Thread (52 messages) 52 messages, 10 authors, 2015-06-23

Re: [PATCH 00/21] On-demand device registration

From: Alexander Holler <hidden>
Date: 2015-06-11 11:24:42
Also in: dri-devel, linux-fbdev, linux-gpio, linux-i2c, linux-pm, linux-pwm, linux-samsung-soc, linux-tegra, lkml

Am 11.06.2015 um 12:17 schrieb Alexander Holler:
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
quoted
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
[off-list ref] wrote:
quoted
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
quoted
quoted
i2c host comes out, probes the regulator driver, regulator driver
probes and then the regulator_get() call returns.

This requires instrumentation on anything providing a resource
to another driver like those I mentioned and a lot of overhead
infrastructure, but I think it's the right approach. However I don't
know if I would ever be able to pull that off myself, I know talk
is cheap and I should show the code instead.
You would end up with the same problem of deadlocks as currently, and
you
would still need something ugly like the defered probe brutforce to
avoid
them.
Sorry I don't get that. Care to elaborate on why?
Because loading/initializing on demand doesn't give you any solved order
of drivers to initialize. And it can't because it has no idea about the
requirements of other drivers. The reason why it might work better in
the case of the tegra is that it might give you another initialization
order than the one which is currently choosen, which, by luck, might be
a better one.

But maybe I missed something, I haven't looked at the patches at all.
But just loading on demand, can't magically give you a working order of
drivers to initialize. E.g. how do you choose the first driver to
initialize?
Other problems you will run into are time constraints and multithreaded 
drivers.

E.g. we all should know how tricky it sometimes is to avoid deadlocks. 
And with loading on demand, you are extending this problem over the 
initialization of maybe a whole bunch of other drivers which might be 
started by calling one function of another driver. And a function call 
might need a very long time to finish during which an unpredictable 
amount of things may happen.

It would make me wonder if that will end up with a good, usable and as 
simple as possible solution.

Regards,

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