On Sat, Sep 01, 2007 at 05:25:17PM +0200, Julio M. Merino Vidal wrote:
> AIUI, as genfb returns 5 during match and intvid returns 1, autoconf
> should simply discard intvid and use genfb, isn't it? It should
> behave as if intvid's match returned 0, as the last test I did. But
> for some reason there seems to be a problem in this. Or is my
> reasoning wrong?
No, and yes.
Not that anyone should blame you here. autoconf(9) is very confusing,
and in my work-in-progress renewal of the API, I chose to make direct
and indirect configuration unmistakenly distinct.
obio(4) is not a direct configuration bus. That means that the bus
doesn't know its children exist. This is the same as isa(4). Therefore
the "match" function of a driver is really a "probe" function. A direct
configuration bus uses one of the variant of config_search(9) to attach
config_search(9) is driven by the kernel configuration file, and _not_
the hardware. It helps the parent bus enumerates its potential (per the
configuration file) children, and let the drivers _probe_ for devices.
And each time a driver says it found a device (i.e., "match" function
returning non zero), the parent bus lets said driver attach.
If there are two drivers for a given device, then they have to
co-operate, because the parent bus has no way to know they probed the
same actual device.
You have ways around that: for instance, you could use config_defer(9)
in intvid(4) so that it doesn't do any actual work if a genfb(4) has
attached to obio(4).
In the case of direct configuration, things are of course very
different: the parent knows there is a device, and indeed wants the
best driver for it.
Quentin Garnier - [email protected] - [email protected]
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.