Hi Masahiro,
On 20 September 2014 00:56, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-09-20 7:25 GMT+09:00 Simon Glass sjg@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.
Yes and it does make quite a difference in some cases.
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)
Yes.
[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)
s/instantiated/described/ - they are just tables in memory at this stage.
[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.
Well I'm not going to disagree with you about the confusion. But 'device' as in 'struct udevice' is the term which means a single instance of a driver. This same term is used in U-Boot and Linux.
So I would not say that binding couples a driver and a device, rather that binding couples a driver and its information, to produce a device.
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 like this one ^^
I am against a statement:
- It is "information of a driver"
Agreed.
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.
OK. I'm resisting because I'm not sure that device_info is better, particularly when we already have udevice. Looking at it another way, driver_info is the info you need to find the driver so you can bind a device to it. I'm happy to change it if we have something obviously better.
Regards, Simon