>Some busses can detect the presence of a particular child device on a
>particular "address" (=locator argument in the kernel config file), e.g.
>PCI. So the bus driver knows "there is this device". Therefore it calls
>config_found_sm(). config_found_sm() looks in the driver table of the
>kernel for the best matching child device driver by using
>config_search()[1]. If a child is found its attach function is called by
>config_found_sm(). I.e. the bus driver calls for each child device it
>detects config_found_sm() and all is done. The bus driver doesn't need
>to care about to call the child device attach function. => direct
>configuration

I assume the driver table will be created in some tree format;
               P1 -> C1, C2, C3, C4
               P2 -> C1, C2, C3, C4
If C4 is another type of bus then that will become a parent.
               C4 -> c1, c2 , c3, c4
Where C4 is the parent device for the c1, c2, c3, c4 and as well as a child 
to P1

Now for considering an example the way mentioned in kernel configuration 
file:
C3 at P1 memaddr 0x8000

In the kernel config file (for example mentioned above) the Parent (P1) is 
informed that it should find this child device (C3) at the address specified 
by the locator "memaddr". So now the parent P1 will try to read a value from 
that address and verifies it. If it is valid (why to validate? : because the 
device may or may not be connected) then a search is made for the child 
device driver and initialized. Now, I assume, the parent P1 will call 
(config_found_sm) all the child drivers match function in order C1, C2, C3 
.... as mentioned in the config file (This is because I had written a PCI 
dummy driver with only the match and attach implmentation, and the match 
function was called for all PCI child devices found on the bus). The best 
match return will configure the driver by calling its attach function. Is 
the concept what I understand is correct, if NOT please guide me.
So according to me the bus driver is told that it should find this device at 
the address specified by the locator - Direct Configuration.

>Some busses can _not_ detect the presence of a particular child device
>on a particular "address", e.g. ISA.
Now my question is why cant a bus driver detect a device specified at a 
particular address. Since the bus driver has to simply read the address 
specified by the locator and validate it. Is there any solid reason for the 
bus driver not able to recognize the child device.

>So the bus driver callsconfig_search() _once_ to find _all_ its child 
>devices. config_search()
>doesn't care about calling the childs attach functions. The bus driver
>has to care about this via the "func()" parameter to the config_search()
>function.[2] config_search() calls the "func()" function for each
>potential child. The bus driver has to supply this "func()" function. It
>has to apply the match function of the current child and if a match was
>found it calls config_attach() for the child. => indirect configuration
Now from the above sentence I assume that, when a parent finds a device 
attached to it, it calls all the possible child device drivers. Like P1 
found C? , is C? = C1/C2/C3/C4. Now the verification and validation part of 
the child device are pushed to the child device drivers. Is that so?


If what ever I assume is correct then the simple sentence to differentiate 
between the configuration types would be:

Direct Configuration: Parent recognizes the type of child device and looks 
for the particular child driver which may or may not be present.

Indirect Configuration: Parent recongnizes a child but does not know what 
type of device, so tries to call all the potential child device driver to 
verify and validate that device. The best match will be the child driver.

Sorry if its confusing.

Anand

_________________________________________________________________
Need more e-mail storage? Get 10MB with Hotmail Extra Storage.   
http://join.msn.com/?PAGE=features/es