[U-Boot] Many questions about U-Boot's Driver Model

[Masahiro YAMADA]

Hi Simon,



2014-09-20 7:25 GMT+09:00 Simon Glass <sjg at chromium.org>:

> - the bind/unbind allows you to have devices which are known to the
> system, but not yet probed. This is important in a boot loader (e.g.
> we don't want to probe devices until they are actually needed, and
> some will never be probed during a boot), although not really
> necessary in an OS

Uh, this view was missing from my mind.
It is nice for faster boot.




> Platform data is bound to the driver to create an new device (instance
> of the driver, if you prefer). Linux has the same concept. See for
> example struct platform_device_info.
>
> Private data is used by that device to hold its information while it
> is active. Linux devices have this, normally in the ->p->driver_data
> member,. See dev_get_drvdata().

Now it is clearer.

In Linux, "platform" looks like a bus,
but in U-Boot it is implemented in the basic infrastructure
(and it seems reasonable enough)




>>
>> [4] What does "struct driver_info" stand for?
>
> It is the information used to bind platform data to a driver to
> produce a device. See Linux's struct platform_device which is similar
> (although in Linux the device is included in the structure).
>
>>
>> I cannot understand the following comment block at all.
>>
>> /**
>>  * struct driver_info - Information required to instantiate a device
>>  *
>>  * @name:       Device name
>>  * @platdata:   Driver-specific platform data
>>  */
>> struct driver_info {
>>         const char *name;
>>         const void *platdata;
>> };
>>
>>
>>
>> Does this structure give information of a driver or a device?
>
> driver + platform data = device


Sorry, I am still not convinced with this part.


In my mind, things happen in the following step:

[1] Every driver is instantiated by U_BOOT_DRIVER()
[2] Every device is instantiated by U_BOOT_DEVICE() (= struct driver_info)
[3] If the system finds a driver and a device with the same name, they are bound


[1] and [2] occur at the build time
[3] occurs at run time  (more exactly, when dm_init_and_scan()
function is called)


At the build time (i.e.  [3] hasn't happened yet), struct driver_info
is information belonging to a *device*.
(This is why I thought "struct driver_info" should be more likely
"struct device_info".)


After [3] happens, you are right, the device's information is attached
to the driver
and driver + platform data = device.
That's what "binding" is for.

Eventually, your explanation in pointing to the same one in my mind.
But there is a slight difference of a nuance.

In my understanding, "binding" is an action that couples a driver and
a device together
by finding the same name.   (In the device tree world, by finding
compatible ones)

Mixing up a driver and a device results in confusion.




>>
>> I am wordering if "struct driver_info" should have been named "struct device_info"?
>>
>
> Possibly, although that might be confusing also, since it is not
> really information about a device. The idea is that it is the info
> needed for a driver to instantiate a new device.

Indeed, it is information about a device.
because .platdata is an attribute of each *device*, right?


I am for statements:
  - It is "information of a device"
  - It is "information for a driver" to bind this device

I am against a statement:
  - It is "information of a driver"



>> I think comments and namings are confusing.
>>
>
> Well it looks like you have found some errors in the comments - we
> should get those fixed. If you have time, please send a patch!

I do not mind if it is a matter of accidental errors in comments. Send
a patch and fix them, that's it.
But I don't think so.

I suspect the struct driver_info is confusing enough and these errors
happened because of that.



-- 
Best Regards
Masahiro Yamada