struct bus_type中为设备和驱动准备了两个链表,而代表设备的结构体struct device中又有两个成员,struct bus_type *bus和struct device_driver *driver。同样,代表驱动的结构体struct device_driver同样有两个成员,struct bus_type *bus和struct list_head devices,struct device和struct device_driver的定义和struct bus_type一样,在include/linux/device.h中。凭直觉,可以知道,struct device中的bus记录的是这个设备连在哪条总线上,driver记录的是这个设备用的是哪个驱动。反过来,struct device_driver中的bus代表的也是这个驱动属于哪条总线,devices记录的是这个驱动支持的那些设备。没错,是devices(复数),而不是device(单数),因为一个驱动程序可以支持一个或多个设备,反过来一个设备则只会绑定给一个驱动程序。
于是我们想知道,关于bus,关于device,关于driver,它们是如何建立联系的呢?换而言之,这三个数据结构中的指针是如何被赋值的?绝对不可能发生的事情是,一旦为一条总线申请了一个struct bus_type的数据结构之后,它就知道它的devices链表和drivers链表会包含哪些东西,这些东西一定不会是先天就有的,只能是后来填进来的。
而具体到USB系统,完成这个工作的就是USB Core。USB Core的代码会进行整个USB系统的初始化,比如申请struct bus_typeusb_bus_type,然后会扫描USB总线,看线上连接了哪些USB设备。或者说Root Hub上连了哪些USB设备,比如说连了一个USB键盘,那么就为它准备一个struct device,根据它的实际情况,为这个struct device赋值,并插入devices链表中来。又比如Root Hub上连了一个普通的Hub,那么除了要为这个Hub本身准备一个struct device以外,还得继续扫描看这个Hub上是否又连了别的设备,如果有的话继续重复之前的事情,这样一直进行下去,直到完成整个扫描,最终就把usb_bus_type中的devices链表给建立了起来。
那drivers链表呢?这个就不用bus方面主动了,而该由每一个驱动本身去bus上面登记,或者说挂牌。具体到USB系统,每一个USB设备的驱动程序都会有一个struct usb_driver结构体,其代码如下,来自include/linux/usb.h:
833 struct usb_driver {
834 const char *name;
835
836 int (*probe) (struct usb_interface*intf,
837 const struct usb_device_id *id);
838
839 void(*disconnect) (struct usb_interface *intf);
840
841 int (*ioctl) (struct usb_interface*intf, unsigned int code,
842 void *buf);
843
844 int (*suspend) (struct usb_interface *intf,pm_message_t message);
845 int(*resume) (struct usb_interface *intf);
846
847 void(*pre_reset) (struct usb_interface *intf);
848 void (*post_reset) (structusb_interface *intf);
849
850 conststruct usb_device_id *id_table;
851
852 structusb_dynids dynids;
853 struct usbdrv_wrap drvwrap;
854 unsignedint no_dynamic_id:1;
855 unsignedint supports_autosuspend:1;
856 };
857 #define to_usb_driver(d) \
container_of(d,struct usb_driver, drvwrap.driver)
此刻我们只需注意到其中的structdevice_driver driver这个成员,USB Core为每一个设备驱动准备了一个函数,让它把这个struct device_driver driver插入到usb_bus_type中的drivers链表中去。而这个函数正是我们此前看到的usb_register。而与之对应的usb_deregister函数所从事的正是与之相反的工作,把这个结构体从drivers链表中删除。
可以说,USB Core的确是用心良苦,为每一个USB设备驱动做足了功课,正因为如此,作为一个实际的USB设备驱动,它在初始化阶段所要做的事情就很少,很简单了,直接调用usb_register即可。事实上,没有人是理所当然应该为你做什么的,但USB Core这么做了。所以每一个写USB设备驱动的人应该铭记,USB设备驱动绝不是一个人在工作,在他身后,是USB Core所提供的默默无闻又不可或缺的支持。