|
- UID
- 852665
|
Linux那些事儿之我是Hub(17)八大重量级函数闪亮登场(一)
还有人记得1996年那部史诗般的电视剧<<英雄无悔>>吗?那年我初二.这部戏让我认识了濮存昕,也是这部戏确立了濮存昕少妇杀手的地位,后来大肆那年濮存昕去过复旦,宣传艾滋病方面的知识,尽管那时候我正在求职的路上遭遇种种挫折,但还是抽出了时间去五教看了听了他的讲座,完了之后他还即兴了一段朗诵.我觉得他身上那种健康的形象是我喜欢的,因为这种积极向上的东西我太缺了.
<<英雄无悔>>里面濮存昕扮演的公安局长高天有一句最经典的话:世上注定会有撑船人和坐船人,而他应该是那个执著的撑船仔.其实hub在usb世界里扮演的又何尝不是这种角色呢?我们来看这个循环,这是Hub驱动中最核心的代码,然而这段代码却自始至终是在为别的设备服务.
在这个循环中,主要涉及这么八个重量级函数,先点明它们的角色分工.
第一个函数,usb_alloc_dev(),为一个struct usb_device结构体指针,申请内存,这个结构体指针可不是为hub准备的,它正是为了hub这个端口所接的设备而申请的,别忘了我们此时此刻的上下文,之所以进入到了这个循环,是因为我们的Hub检测到某个端口有设备连接了进来,所以我们作为Hub驱动当然就义不容辞的要为该设备做点什么.
第二个函数,usb_set_device_state(),这个函数用来设置设备的状态,struct usb_device结构体中,有一个成员,enum usb_device_state state,这一刻,会把这个设备的状态设置为USB_STATE_POWERED,即上电状态.
第三个函数,choose_address(),为设备选择一个地址.一会咱们会用实例来看看效果.
第四个函数,hub_port_init(),不多说了,这个就是端口初始化,主要就是前面说的获取设备的描述符.
第五个函数,usb_get_status(),这个函数是专门为hub准备的,不是为当前的这个hub,而是说当前hub的这个端口上连接的如果又是hub,那么和连接普通设备当然不一样.
第六个函数,check_highspeed(),不同速度的设备当然待遇不一样.
第七个函数,usb_new_device().寻找驱动程序,调用驱动程序的probe,跟踪这个函数就能一直跟踪到设备驱动程序的probe()函数的调用.
第八个函数,hub_power_remaining(),别忘了,电源管理将是hub驱动永恒的话题.
Ok,下面就让我们来认真的逐个看一看这八大函数.
usb_alloc_dev(),drivers/usb/core/usb.c:
226 /**
227 * usb_alloc_dev - usb device constructor (usbcore-internal)
228 * @parent: hub to which device is connected; null to allocate a root hub
229 * @bus: bus used to access the device
230 * @port1: one-based index of port; ignored for root hubs
231 * Context: !in_interrupt()
232 *
233 * Only hub drivers (including virtual root hub drivers for host
234 * controllers) should ever call this.
235 *
236 * This call may not be used in a non-sleeping context.
237 */
238 struct usb_device *
239 usb_alloc_dev(struct usb_device *parent, struct usb_bus *bus, unsigned port1)
240 {
241 struct usb_device *dev;
242
243 dev = kzalloc(sizeof(*dev), GFP_KERNEL);
244 if (!dev)
245 return NULL;
246
247 if (!usb_get_hcd(bus_to_hcd(bus))) {
248 kfree(dev);
249 return NULL;
250 }
251
252 device_initialize(&dev->dev);
253 dev->dev.bus = &usb_bus_type;
254 dev->dev.type = &usb_device_type;
255 dev->dev.dma_mask = bus->controller->dma_mask;
256 dev->state = USB_STATE_ATTACHED;
257
258 INIT_LIST_HEAD(&dev->ep0.urb_list);
259 dev->ep0.desc.bLength = USB_DT_ENDPOINT_SIZE;
260 dev->ep0.desc.bDescriptorType = USB_DT_ENDPOINT;
261 /* ep0 maxpacket comes later, from device descriptor */
262 dev->ep_in[0] = dev->ep_out[0] = &dev->ep0;
263
264 /* Save readable and stable topology id, distinguishing devices
265 * by location for diagnostics, tools, driver model, etc. The
266 * string is a path along hub ports, from the root. Each device's
267 * dev->devpath will be stable until USB is re-cabled, and hubs
268 * are often labeled with these port numbers. The bus_id isn't
269 * as stable: bus->busnum changes easily from modprobe order,
270 * cardbus or pci hotplugging, and so on.
271 */
272 if (unlikely(!parent)) {
273 dev->devpath[0] = '0';
274
275 dev->dev.parent = bus->controller;
276 sprintf(&dev->dev.bus_id[0], "usb%d", bus->busnum);
277 } else {
278 /* match any labeling on the hubs; it's one-based */
279 if (parent->devpath[0] == '0')
280 snprintf(dev->devpath, sizeof dev->devpath,
281 "%d", port1);
282 else
283 snprintf(dev->devpath, sizeof dev->devpath,
284 "%s.%d", parent->devpath, port1);
285
286 dev->dev.parent = &parent->dev;
287 sprintf(&dev->dev.bus_id[0], "%d-%s",
288 bus->busnum, dev->devpath);
289
290 /* hub driver sets up TT records */
291 }
292
293 dev->portnum = port1;
294 dev->bus = bus;
295 dev->parent = parent;
296 INIT_LIST_HEAD(&dev->filelist);
297
298 #ifdef CONFIG_PM
299 mutex_init(&dev->pm_mutex);
300 INIT_DELAYED_WORK(&dev->autosuspend, usb_autosuspend_work);
301 dev->autosuspend_delay = usb_autosuspend_delay * HZ;
302 #endif
303 return dev;
304 }
首先是申请内存,申请一个struct usb_device结构体指针的内存,这个指针就是dev,bus就是总线,这里传递进来的两个实参我们看到,一个是hdev,一个是hdve->bus,hdev自然很明确,就是hub所对应的那个struct usb_device指针,它的bus当然更加明确,一个主机控制器就对应一条总线,那么不管我们在哪里说,都是那条总线.bus是struct usb_bus结构体指针,而bus_to_hcd()得到的就是该总线对应的主机控制器,江湖上的人都知道,主机控制器就是代表一条总线.主机控制器由一个结构体struct usb_hcd表示,struct usb_hcd定义于drivers/usb/core/hcd.c,它有一个成员,struct usb_bus self.那么这里bus_to_hcd()就是得到该bus所属于的那个struct usb_hcd所对应的指针,usb_get_hcd()是增加引用计数,具体怎么实现咱们在设备模型里面有过交待.这里很显然,因为这个主机控制器的总线上多了一个设备,当然得为主机控制器增加引用计数,只要有设备在,主机控制器的数据结构就得在,否则系统肯定挂了.这里如果usb_get_hcd()失败了那就没啥好说的了,释放内存吧,哪凉快去哪待着.
然后device_initialize(&dev->dev),初始化设备,第一个dev是struct usb_device结构体指针,而第二个dev是struct device结构体,这是设备模型里面一个最最基本的结构体,使用它必然要先初始化,device_initialize就是内核提供给咱们的初始化函数.
接下来,关于struct device结构体,我们迫不得已必须讲两句了,熟悉2.6设备模型的兄弟们一定知道struct device.我们其实已经见过很多次了,在usb-storage的故事里见过,在hub的故事里此前也见过,只是一直没有把它的定义贴出来,因为那时候总觉得没有必要,但现在,关于这个结构体的成员出镜率越来越高,我不得不把它的定义贴出来.正如<<无间道>>里所说的那样,从来只有事情改变人,人不可能改变事情.这个结构体定义于include/linux/device.h:
410 struct device {
411 struct klist klist_children;
412 struct klist_node knode_parent; /* node in sibling list */
413 struct klist_node knode_driver;
414 struct klist_node knode_bus;
415 struct device *parent;
416
417 struct kobject kobj;
418 char bus_id[BUS_ID_SIZE]; /* position on parent bus */
419 struct device_type *type;
420 unsigned is_registered:1;
421 unsigned uevent_suppress:1;
422 struct device_attribute uevent_attr;
423 struct device_attribute *devt_attr;
424
425 struct semaphore sem; /* semaphore to synchronize calls to
426 * its driver.
427 */
428
429 struct bus_type * bus; /* type of bus device is on */
430 struct device_driver *driver; /* which driver has allocated this
431 device */
432 void *driver_data; /* data private to the driver */
433 void *platform_data; /* Platform specific data, device
434 core doesn't touch it */
435 struct dev_pm_info power;
436
437 #ifdef CONFIG_NUMA
438 int numa_node; /* NUMA node this device is close to */
439 #endif
440 u64 *dma_mask; /* dma mask (if dma'able device) */
441 u64 coherent_dma_mask;/* Like dma_mask, but for
442 alloc_coherent mappings as
443 not all hardware supports
444 64 bit addresses for consistent
445 allocations such descriptors. */
446
447 struct list_head dma_pools; /* dma pools (if dma'ble) */
448
449 struct dma_coherent_mem *dma_mem; /* internal for coherent mem
450 override */
451 /* arch specific additions */
452 struct dev_archdata archdata;
453
454 spinlock_t devres_lock;
455 struct list_head devres_head;
456
457 /* class_device migration path */
458 struct list_head node;
459 struct class *class;
460 dev_t devt; /* dev_t, creates the sysfs "dev" */
461 struct attribute_group **groups; /* optional groups */
462
463 void (*release)(struct device * dev);
464 };
又是一个暴长的结构体,所以说其实当初我不贴出来也是为了你好.
对着这个结构体来解释代码,dev.bus就是struct bus_type的指针,bus_type顾名思义就是总线类型,对于usb设备来说,你可以搜索整个drivers/usb/目录下的代码,你会发现,其实总共就是定义过两个类型,一个是定义于drivers/usb/core/driver.c中的struct bus_type usb_bus_type,另一个是定义于drivers/usb/serial/usb-serial.c中的struct bus_type usb_serial_bus_type.后者干嘛用的不用我说了吧,整个drivers/usb/serial/目录就是专门为usb-to-serial而准备的,串口方面的,咱们不必理睬.所以在咱们的故事中,不管你在哪里看到struct bus_type的指针,它的指向都一样,就是usb_bus_type.到drivers/usb/core/driver.c里面看一下这个变量的定义.
1523 struct bus_type usb_bus_type = {
1524 .name = "usb",
1525 .match = usb_device_match,
1526 .uevent = usb_uevent,
1527 .suspend = usb_suspend,
1528 .resume = usb_resume,
1529 };
实际上在usb系统的一开始的初始化代码就有这么一句,bus_register(&usb_bus_type),就这句让系统知道有这么一个类型的总线.不过需要强调的是,一个总线类型和一条总线可别混淆了,从硬件上来讲,一个host controller就会连出一条usb总线,而从软件上来讲,不管你有多少个host controller,或者说有多少条总线,它们通通属于usb_bus_type这么一个类型,只是每一条总线对应一个struct usb_bus结构体变量,也正是前面我们刚刚说过的那个struct usb_hcd中那个叫做self的成员(struct usb_hcd中struct usb_bus self),这个变量在主机控制器的驱动程序中来申请.总线类型和具体的总线这种关系正如C++中的类和对象,不要跟我说你不知道类和对象的关系.那我只能解释说,我身边有两类人,一类是有对象的,一类是没有对象的…
Ok,确定了dev.bus指向usb_bus_type之后,下一个dev.type,struct device_type结构体指针,这个就真的不用再解释了,其作用和struct bus_type一样,即总线有总线的类型,设备也有设备的类型,正所谓物以类聚.这里等号右边的usb_device_type来自drivers/usb/core/usb.c,
195 struct device_type usb_device_type = {
196 .name = "usb_device",
197 .release = usb_release_dev,
198 };
现在我们还不需要去认识这个结构体内部,只是知道我们的所有的usb设备都会属于usb_device_type这么一类就可以了,这个只是为了让我们从软件的角度来说方便管理而已.
然后dma_mask,这个就是与DMA传输相关的了,设备能不能进行dma传输,得看主机控制器的脸色,主机控制器不支持的话设备自作多情那也没有用.所以这里dma_mask被设置为host controller的dma_mask.注意到我们在struct usb_hcd结构体里有一个struct usb_bus self,而在struct usb_bus结构体里又有一个struct device * controller,实际上struct usb_hcd和struct usb_bus都是为主机控制器而准备的数据结构,只是分工不一样,你要是看它们不爽也可以考虑把它们合并为一个结构体,不过我估计开源社区的那帮家伙不会同意你这样乱来.
256行,dev->state,这里dev就是struct usb_device的意思了,而关于state,我们必须很清楚,这是调试usb设备驱动的基础.你如果连usb设备有哪些状态都不知道的话,你不要跟人说你会调试usb设备驱动程序,真的,丢不起那人.struct usb_device里面有一个成员,enum usb_device_state state,这是一个枚举的数据类型.
在include/linux/usb/ch9.h中有定义,
557 enum usb_device_state {
558 /* NOTATTACHED isn't in the USB spec, and this state acts
559 * the same as ATTACHED ... but it's clearer this way.
560 */
561 USB_STATE_NOTATTACHED = 0,
562
563 /* chapter 9 and authentication (wireless) device states */
564 USB_STATE_ATTACHED,
565 USB_STATE_POWERED, /* wired */
566 USB_STATE_UNAUTHENTICATED, /* auth */
567 USB_STATE_RECONNECTING, /* auth */
568 USB_STATE_DEFAULT, /* limited function */
569 USB_STATE_ADDRESS,
570 USB_STATE_CONFIGURED, /* most functions */
571
572 USB_STATE_SUSPENDED
573
574 /* NOTE: there are actually four different SUSPENDED
575 * states, returning to POWERED, DEFAULT, ADDRESS, or
576 * CONFIGURED respectively when SOF tokens flow again.
577 */
578 };
这些都是usb设备的可能状态,在usb spec中有定义,但是有些在usb spec里面没有,只是这里设置的,从软件的角度来说对usb设备的状态进行更细的划分.在usb spec 2.0中一共定义了6种状态,分别是Attached,Powered,Default,Address,Configured,Suspended.那么咱们这里所谓的USB_STATE_NOTATTACHED就是表征设备并没有Attached,而咱们此时此刻设置的是USB_STATE_ATTACHED就是做为当检测到设备时的初始状态.
端点0的特殊地位决定了她必将受到特殊的待遇.在struct usb_device结构体中就有一个成员struct usb_host_endpoint ep0,而它的urb_list也是在这里就要先初始化了.
ep0.desc就是该端点的描述符,端点描述符的长度总是7个字节,这是usb spec规定的,即endpoint的描述符中bLength为7.宏USB_DT_ENDPOINT_SIZE就是被定义为7.bDescriptorType就是描述符类型,描述符既然有设备描述符,有接口描述符,有端点描述符,等等,当然就有一个类别的说法,要不怎么区分呢?如下图所示,usb spec里定义了端点描述符的类别就是5,
而咱们的代码里定义了USB_DT_ENDPOINT这个宏就是0x05,所以这里没什么好说的.一切按规矩办事.
ep_in和ep_out就是两个数组,是struct usb_device中的两个成员,struct usb_host_endpoint *ep_in[16]和struct usb_host_endpoint *ep_out[16],一个设备就是最多有32个管道,16个进,16个出,基本上一个端点对应一个管道.考你一下,知道我为什么不直接说一个设备最多有32个端点?理由很简单,端点0太太太太太特殊了,别的端点不是进就是出,但是端点0是双向的,既可以收也可以发.所以对它,我们需要以ep_in[0]和ep_out[0]来记录.
接下来的几个变量,parent自不必说,没有它就没法形成一棵usb设备树,USB设备树上的每一个设备都得有parent,只有Root Hub没有,正所谓树欲静而风不止,子欲孝而亲不在.当我刚看到这段if语句的时候,觉得它真是荒唐,咱们现在不是在hub驱动程序中,在判断端口有连接设备了才执行这段代码的吗,hub端口里面怎么会连接有Root Hub呢?但转念一想,不对,这种想法太幼稚了点,有一位伟人的话说,我这叫too simple, sometimes naïve.的确我们是在这种情景下调用usb_alloc_dev的,可是这个函数并非只有我们调用啊,别人也会调用,在host controller的驱动中就会调用,它就要为Root hub申请内存啊,所以对于usb_alloc_dev函数来说当然就应该判断这个设备是不是Root Hub了.在Host Controller驱动程序中,调用这个函数的时候传递的parent就是NULL,所以这里这个if就是用来区分这两种情况的.我们来仔细看一下这个if内部的赋值.
首先是devpath,然后是dev.bus_id,最后是busnum.重点来看devpath, struct usb_device结构体中char devpath[16],很显然这将会用来记录一个字符串,这个字符串啥意思?给你看个直观的东西,
localhost:~ # ls /sys/bus/usb/devices/
1-0:1.0 2-1 2-1:1.1 4-0:1.0 4-5:1.0 usb2 usb4
2-0:1.0 2-1:1.0 3-0:1.0 4-5 usb1 usb3
Sysfs文件系统下,我们看到这些乱七八糟的东西,它们都是啥?usb1/usb2/usb3/usb4表示哥们的计算机上接了4条usb总线,即4个usb主机控制器,事物多了自然就要编号,就跟我们中学或大学里面的学号一样,就是用于区分多个个体,而4-0:1.0表示什么?4表示是4号总线,或者说4号Root Hub,0就是这里我们说的devpath,1表示配置为1号,0表示接口号为0.也即是说,4号总线的0号端口的设备,使用的是1号配置,接口号为0.那么devpath是否就是端口号呢?显然不是,这里我列出来的这个例子是只有Root Hub没有级联Hub的情况,如果在Root Hub上又接了别的Hub,然后一级一级连下去,子又生孙,孙又生子,子又有子,子又有孙.子子孙孙,无穷匮也.那么如何在sysfs里面来表征这整个大家族呢?这就是devpath的作用,顶级的设备其devpath就是其连在Root Hub上的端口号,而次级的设备就是其父Hub的devpath后面加上其端口号,即如果4-0:1.0如果是一个Hub,那么它下面的1号端口的设备就可以是4-0.1:1.0,2号端口的设备就可以是4-0.2:1.0,3号端口就可以是4-0.3:1.0.总的来说,就是端口号一级一级往下加.这个思想是很简单的,也是很朴实的.
至此,我们可以来一次性看一下272行到291行这一段代码了.首先判断如果是Root Hub,那么直接赋值dev->devpath[0]为’0’,以示特殊,然后父设备设为controller,同时把dev->bus_id[]设置为像usb1/usb2/usb3/usb4这样的字符串.如果不是Root Hub,那么两种情况,第一种,如果是连接在Root Hub上,dev->path就是等于端口号,第二种,如果不是连接在Root Hub上,那么就是在父设备的devpath基础上加上一个端口号,在父设备的devpath和端口号之间用一个点”.”连接起来.最后把bus_id[]设置成usb1/usb2/usb3/usb4这样的字符串后面连接上devpath.
接下来293到295这三行就不用多说了,白痴都知道.
296行,初始化一个队列.这个队列干嘛用的?usbfs会用到,只要你够帅,你就能看到在/proc/bus/usb/下面有很多usb相关的信息.每个usb设备会在这下面对应一个文件,这个文件系统称为USB设备文件系统.你可以用下面这条命令挂载这个文件系统:
mount –t usbfs none /proc/bus/usb
然后你cat /proc/bus/usb/devices就能看到那些系统里usb设备的信息.对usbfs的实现在drivers/usb/core/inode.c以及drivers/usb/core/devices.c这两个文件中.现在把这个队列初始化为空,不久的将来,当您打开设备在usbfs中对应的文件时,这个队列就会加入东西.
298行,又涉及到电源管理的部分了,首先是初始化一个互斥锁,pm_mutex,struct usb_device中的成员,struct mutex pm_mutex.然后是调用INIT_DELAYED_WORK(),这个咱们不陌生吧,前面专门讲过的.不过需要解释的是,autosuspend,自动挂起,在struct usb_device中也有一个成员,struct delayed_work autosuspend,而usb_autosuspend_work()是定义于drivers/usb/core/driver.c中的一个函数.先不管这个函数干嘛的,至少咱们通过这句话可以知道,在明天的明天的明天,在未来的某年某月某一天的某个时刻,usb_autosuspend_work()函数会被调用.具体是什么时刻,咱们先甭管,到时候再说.而autosuspend_delay就很简单了,就是延时,一样的,等到用的时候再来说,不过需要注意的是,这个冬冬被赋值为usb_autosuspend_delay*HZ,其中usb_autosuspend_delay又是一个模块加载参数,
54 #ifdef CONFIG_USB_SUSPEND
55 static int usb_autosuspend_delay = 2; /* Default delay value,
56 * in seconds */
57 module_param_named(autosuspend, usb_autosuspend_delay, int, 0644);
58 MODULE_PARM_DESC(autosuspend, "default autosuspend delay");
59
60 #else
61 #define usb_autosuspend_delay 0
62 #endif
如果您打开了CONFIG_USB_SUSPEND,那么这个值默认就是2,您当然可以自己修改,在您加载模块usbcore模块的时候作为一个参数传递进来就可以了.如果您没打开CONFIG_USB_SUSPEND,那么不必说,直接就是定义为0,也没有意义.
Ok,到这里,我们走完了八大函数的第一个.路漫漫其修远兮,让我们荡起双桨上下而求索. |
|
