Re: [RFC PATCH 2/9] dt: deps: dependency based device creation

[Alexander Holler]

Am 18.05.2014 16:59, schrieb Grant Likely:
> Hi Tomasz,
>
> Thanks for weighing in on this. Thoughts and comments below.
>
> On Sat, 17 May 2014 16:24:19 +0200, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote:

> registration order. Alexander had to hook into the driver registration
> patch to get the optimal probe order. For device order to be effective,

I had to hook into the driver registration to get information about the 
(available) drivers. Without the hook it is currently impossible to 
identify drivers before they start doing things.

To reccover, I had to solve several problems:

- Getting dependencies (happens almost automatically by using phandle 
references)
- Get them to the kernel (done by using a new property)
- Build order (already a solved problem, think at make)
- Identify available drivers (invented hook, "well done" is meant in 
regard to this feature, I needed a name and found "well done" apropriate 
because it too might stimulate driver authors to use it)
- Check out how to handle/start/register devices and drivers (in order).

I think the last one is the most unfinished and questionable part.

The part to identify drivers could be done much better by linking an 
array of struct platform_driver, but in order to use such an array, 
drivers have to be done "well done" too (which means no action before 
probe). So that well-done hook can be seen as an intermediate step.

> Having said that, there are some things that I worry about. I worry
> about the cost of doing dependency sorting, both in calculating the
> dependency tree and in pushing back probe calls to the end of initcalls.

Building and calculating the dependency tree just needs a few ms and I 
think it's much faster than what is necessary afterwards, all those 
string compares to match drivers/devices.

But this string compares already do happen, and I think this part could 
optimized a lot, when a list of drivers and their compatibility strings 
is available. Then it's possible to build a hash or e.g. radix tree 
which leads from the compatibility string to the available driver(s).

> I worry that incorrect dependency information will cause some devices to
> not get bound (say because the kernel things the dependency isn't met
> when it actually is).

All (not started) drivers and (unbounded) devices can still be 
registered/bound after those which appear in the order. That would be 
just like before.

But as said, the whole handling which happens after the order was build 
is done quick & dirty, done with missing knownledge about the device 
model, and might contain a lot of bugs and even might need that some 
drivers will be changed.

Therefor all changes disappear when CONFIG_OF_DEPENDENCIES is disabled. 
So tested platforms might use it (taking advantage of a deterministic 
order in order to get rid of hardcoded stuff to fix the order) and 
others don't have to care.

So, as already said, I've posted these patches to make evaluation easy, 
without the need to discuss just ideas but something real to play with 
(in order to get something happen on this front, not just hardcoded 
hacks done in individual drivers because such passes maintainers easier).

I didn't cared much about form or how to split those patches into more 
convenient parts. That is stuff where I just do it like a maintainer 
does want it. I did them as I like them, and I don't want to end up in a 
time wasting discussions about form, style or similiar questions.

So if anyone would be comfortable to merge these patches (for evaluation 
by others) in other form or splitted in more parts, I will just hear and do.

I also don't have any objections in changes in the stuff which happens 
after the order was build. In fact I would even like it if someone with 
more experience with the driver model would do it. I just had to do 
something there too, otherwise it would still have been just an idea 
which wouldn't offer much motivation to actually look at it.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/