一，前言
之前看到关于设置gpio有多好api，这个c中的api可以，那个c中的api也可以，感觉有些混乱。所以我又细看了下，发现根本原因是我把uclass中的driver和uclass_driver弄乱了。
二，分析
1. device_bind_common中会创建device，其中name是哪里来的？
答：其实就是driver结构体中的name成员值。
a)
dm_scan
dm_scan_plat
lists_bind_drivers
bind_drivers_pass
device_bind_by_name
device_bind_common
b)
dm_init
->device_bind_by_name(&root_info)
->device_bind_common(info->name)
static struct driver_info root_info = {
.name = "root_driver",
};
所以对于dm_init的info_name就是root_driver。另外一个特点device_bind_common前先要drv = lists_driver_lookup_name(info->name);这个info->name其实就是通过U_BOOT_DRIVER注册的driver结构体的.name。由于root_driver应该找不到，所以为device创建name是在dm_scan的路径。它会遍历driver。
2. driver和uclass_driver的区别？
答：driver就是去match device的。每个uclass中有很多device，每个device都绑定了具体实现操作的driver。对于一类设备，比如gpio，uclass对象仅一个，而uclass_driver就可以理解为某个uclass对于的driver，用来提供抽象的接口，便于操作下层具体的设备驱动。所以uclass_driver可以理解为中间层。比如board.c中要操作led灯，比较好的方法就用led的uclass，传入设备名称即可对齐操作。uclass_driver会遍历此uclass下的所有led设备，与name匹配后就找到device，然后调用device的driver->ops进行操作即可。所以若驱动都用，仅板子元素不同，应该最常用的就是uclass中的api来重写board.c然后就是修改设备树中的io，就完成一块板子的简单变更了。
3.关系图
三，小结
还是画一个图来说明uclass和uclass_driver，device和driver的层次关系比较好。