Hi Simon,
2014-09-20 7:25 GMT+09:00 Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot