Thread (85 messages) 85 messages, 10 authors, 2014-08-29

[RFC PATCH 5/9] dt: deps: register drivers based on the initialization order based on DT

From: Alexander Holler <hidden>
Date: 2014-05-14 14:58:51
Also in: linux-devicetree, lkml

Am 14.05.2014 16:13, schrieb Grant Likely:
On Mon, 12 May 2014 18:47:56 +0200, Alexander Holler [off-list ref] wrote:
quoted
The init system currently calls unknown functions with almost unknown
functionality in an almost random order.
Correct, we've got a module system. Some would say that is a strength!
:-) That said, I don't object to optimizing to the optimal order when
possible.
Modules do work after init happened, that isn't what this feature is about.
quoted
Fixing this is on a short-term basis is a bit tricky.

In order to register drivers with a deterministic order, a list of all
available in-kernel drivers is needed. Unfortunately such a list doesn't
exist, just a list of initcalls does exist.

The trick now is to first call special annotated initcalls (I call those
"well done") for platform drivers, but not actualy starting those drivers
by calling their probe function, but just collectiong their meta datas
(struct platform_driver). After all those informations were collected,
available the drivers will be started according to the previously
determined order.
Why does the initcall level matter? Why not just let the initcalls
happen, capture the calls that register a driver, and then use that list
later?
Some initcalls assume that stuff is present when they called probe or 
register and do further action based on the rc code.
quoted
The long range target to fix the problem should be to include a list (array)
of struct platform_driver in the kernel for all in-kernel platform drivers,
instead of just initcalls. This will be easy if all platform drivers have
become "well done".
How will that list be constructed? How will it account for multiple
platforms, each requiring a different init order?
The list could be build just like the list of initcalls, but containing 
structs platform instead of function pointers.

The order is in now way part of this list, after all that's what this 
feature is about. The order is determined by metadatas in the DT, to get 
rid of a lot of otherwise necessary hardcoded stuff to fix the order in 
drivers.

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