uboot的driver和uclass_driver的区别？

一，前言

之前看到关于设置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的层次关系比较好。