人工智能

下面接着看那三个基本点。第一个基本点，usb_alloc_urb函数，创建urb的专用函数，为一个urb申请内存并做初始化，在drviers/usb/core/urb.c里定义。struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags){ struct urb *urb; urb = kmalloc(sizeof(stru

struct usb_device结构冗长而又杂乱include/linux/usb.hstruct usb_device { int devnum; char devpath[16]; u32 route; enum usb_device_state state; enum usb_device_speed speed; struct usb_tt *tt; i

从拓扑上来看，USB子系统并不以总线的方式来部署，它是一颗由几个点对点的连接构成的树。它主要包括了USB连接、USB host controller和USB device三个部分。而USB device还包括了hub和功能设备等。下面还是逐个说说吧。什么是USB controller？在一个USB系统中只能有一个host，其实说白了就是咱们的主机，而USB和主机的接

USB core从USB子系统的初始化开始，我们也需要从那里开始，它们在文件drivers/usb/core/usb.c938 subsys_initcall(usb_init);939 module_exit(usb_exit);我们看到一个subsys_initcall，复旦人甲说它也是一个宏，我们可以把它理解为module_init，只不过因为这部分代码比较核心，开发者们把它看作

USB的一生充满了PK，并在PK中发展，1.0、1.1、2.0，漫漫辛酸路，一把辛酸泪。我们又何尝不是，上学碰到实行自费，毕业碰到IT崩溃，工作碰到房价见鬼，现在又碰到股市泡沫，与房价PK，与庄家PK，从来的结局都只有失败一个，USB在PK中发展，我们在PK中只有变老。这张表是从USB2.0 spec里直接拿过来的，可以看出，它的高速模式最高已经达到了480Mbps，即60MB

前面的前面已经说了，接口是设备的接口。设备可以有多个接口，每个接口代表一个功能，每个接口对应着一个驱动。Linux设备模型的device落实在USB子系统，成了两个结构，一个是struct usb_device，一个是struct usb_interface，一个石头砸了两个坑，一支箭射下来两只麻雀，你说怪不怪。怪不怪还是听听复旦人甲怎么说，一个usb设备，两种功能，一个键盘，上面带一个扬声器，两

drivers/usb/core/driver.cstatic int usb_device_match(struct device *dev, struct device_driver *drv){ /* devices and interfaces are handled separately */ if (is_usb_device(dev)) { /* interfac

首先当然是你将usb设备连接在hub的某个端口上，hub检测到有设备连接了进来，它也知道有朋自远方来不亦乐乎，于是精神头儿就上来了，就觉得有必要为设备做点什么。它会为设备分配一个struct usb_device结构的对象并初始化，并调用设备模型提供的接口将设备添加到usb总线的设备列表里，然后usb总线会遍历驱动列表里的每个驱动，调用自己的match函数看它们和你的设备或接口是否匹配。这不，又走

使用命令lsmod，看看它的输出，然后找这么个模块usbcore，不要说你找不到，我不会相信的。它是什么？它就是咱们这里要说的usb系统的核心，如果要在linux里使用usb，这个模块是必不可少的，另外，你应该在usbcore那一行的后面看到ehci_hcd或uhci_hcd这样的东东，它们就是前面说的usb host controller的驱动模块，你的usb设备要工作，合适的usb host

Linux设备模型中的总线落实在USB子系统里就是usb_bus_type，它在usb_init函数注册，在drivers/usb/core/driver.c文件里定义struct bus_type usb_bus_type = { .name = "usb", .match = usb_device_match, .uevent = usb_uevent,};name自然就是u

新气象要用新代码，就使用最新的3.18.2版本的内核了。首先要去drivers/usb目录下走一走看一看。atm class core gadget host image misc mon serial storage Kconfig Makefile README usb-skeleton.cls命令的结果就是上面的10个目录和4个文件。usb-skeleton.c是一个简单的usb d

它从哪里来，它从intel来。不过，与PCI、AGP属于intel单独提出的硬件标准不同，Compaq、IBM、Microsoft等也一起参与了这个游戏，它们一起在94年11月提出了USB，于95年11月制定了0.9版本，96年制定了1.0版本，不过它并没有因为有这些大佬的支持立即迎来它的春天，谁让它诞生在冬天那，生不逢时啊。因为缺乏操作平台的良好支持和大量支持它的产品，这些标准都成了空谈。然后是

int retval; if (nousb) { pr_info("%s: USB support disabled\n", usbcore_name); return 0; }第2行知道C语言的人都会知道nousb是一个标志，只是不同的标志有不一样的精彩，这里的nousb是用来让我们在启动内核的时候通过内核参数去掉USB子系统的，linux社会是一个很人性化的世界，它不会去逼迫我们接

上文说usb_init给我们留下了一些岔路口，每条都像是不归路，让人不知道从何处开始，也看不到路的尽头。趁着徘徊彷徨的档儿，咱们还是先聊一下linux的设备模型。顾名而思义就知道设备模型是关于设备的模型，对咱们写驱动的和不写驱动的人来说，设备的概念就是总线和与其相连的各种设备了。电脑城的IT工作者都会知道设备是通过总线连到计算机上的，而且还需要对应的驱动才能用，可是总线是如何发现设备的，设备又

接着看usb设备的配置吧，在include/linux/usb.h里定义struct usb_host_config { struct usb_config_descriptor desc; char *string; /* iConfiguration string, if present */ /* List of any Interface Association Descr

函数usb_control_msg调用了usb_internal_control_msg之后就去一边儿睡大觉了，脏活儿累活儿，全部留给usb_internal_control_msg去做了，这才叫骨干啊，俺一华为的哥们儿如是说。那么咱们接下来就给这个骨干多点儿关注，了解一下它背后的真实生活，现在是焦点访谈时间，要用事实说话。drivers/usb/core/message.cstatic

端点是USB数据传输的终点。看看它在内核里的定义46 /**47 * struct usb_host_endpoint - host-side endpoint descriptor and queue48 * @desc: descriptor for this endpoint, wMaxPacketSize in native byteorder49 * @urb_list:

我是谁？USB一遍一遍问着自己，当然它不会真的是一颗树。USB只是Linux庞大家族里的一个小部落，host controller是它们的族长，族里的每个USB设备都需要被系统识别，被我们识别。虽然清朝老爷子们不知道闭关锁国没前途，可USB是知道的，sysfs就是它对外的窗口，我们可以从sysfs里了解认识每一个USB设备。生活是简单的，USB是复杂的。USB设备在sysfs中的表示并不是那么

前面struct usb_interface里表示接口设置的struct usb_host_interface就被有意无意的飘过了，咱们在这里看看它的真面目，同样在include/linux/usb.h文件里定义。struct usb_host_interface { struct usb_interface_descriptor desc; int extralen; unsigne

继续urburb_list，还记得每个端点都会有的那个urb队列么？那个队列就是由这里的urb_list一个一个的链接起来的。HCD每收到一个urb，就会将它添加到这个urb指定的那个端点的urb队列里去。这个链表的头儿在哪儿？当然是在端点里，就是端点里的那个struct list_head结构体成员。dev，傻强都知道，它表示的是urb要去的那个usb设备。pipe，urb到达端

回到struct usb_hcd，继续努力的往下看。7行，又见kref，usb主机控制器的引用计数。struct usb_hcd也有自己专用的引用计数函数，看hcd.c文件static void hcd_release(struct kref *kref){ struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref

drivers/usb/core/urb.cint usb_submit_urb(struct urb *urb, gfp_t mem_flags){ static int pipetypes[4] = { PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT }; int xfertype, max;

算是进入了HCD的片儿区，这里的老大不是帮派头目也不是巡逻片儿警，而是几个结构。C里边是以结构为王的，随便到一个新地方，新环境，新山头儿，首先要去结识的就是几个占山为王，雄据一方的结构。在HCD这个片儿区，这个山头儿，王中之王就是include/linux/usb/hcd.h里定义的struct usb_hcd。struct usb_hcd { /* * housekeeping

聊完了struct usb_hcd和struct usb_bus，算是已经向HCD片儿区的老大们拜过山头了，接下来就该看看usb_submit_urb()最后的那个遗留问题usb_hcd_submit_urb()了，要有心理准备，也是个一百多行的狠角色。现在内核里有个很不好的现象，设计结构比复杂，写函数比长。像一个中介语重心长的说：我承认的确房屋中介有不好的现象，收看房费，收差价，很是让人生气，作

现在已经使用GET_DESCRIPTOR请求取到了包含一个配置里所有相关描述符内容的一堆数据，这些数据是raw的，即原始的，所有数据不管是配置描述符、接口描述符还是端点描述符都不分男女不分彼此的挤在一起，这放在今天当然是有伤风化的，再说群租也是要禁止的，所以得想办法将它们给分开，丁是丁卯是卯的，于是usb_parse_configuration()和上海的那个群租管理条例一起登上了历史舞台，显然它

现在开始就沿着usb_generic_driver的成名之路走一走，设备的生命线你可以想当然的认为是从你的usb设备连接到hub的某个端口时开始，驱动的生命线就必须得回溯到usb子系统的初始化函数usb_init了。 retval = usb_register_device_driver(&usb_generic_driver, THIS_MODULE); if (!retval) go

core配置设备使用的是message.c里的usb_set_configuration函数int usb_set_configuration(struct usb_device *dev, int configuration){ int i, ret; struct usb_host_config *cp = NULL; struct usb_interface **new_inte

跟着设备的生命线走到现在，我算是明白了，什么东西的发展都是越往后越高级越复杂。再给张小表，看看现在和上次那张表出现的时候有什么变化。state        USB_STATE_ADDRESSspeed     takenep0         ep0.urb_list，描述符长度/类型，wMaxPacketSize接下来设备的目标当然就是Configured了。要进入

准备工作该做的都做了，别嫌太麻烦，什么事情都要经过这么一个阶段，大家都明白。现在看看第二阶段的重头戏，看看设备是怎么从Address进入Configured的。1501行，如果已经在Configured状态了，就得做些清理工作，退回到Address状态。都清理些什么怎么去清理？别着急，要想学会，得仔细研究下message.c里的usb_disable_device函数。1024 /*102

设备自从有了Address，拿到了各种描述符，就在那儿看usb_generic_driver忙活了，不过还算没白忙，设备总算是幸福的进入Configured了。从设备这儿咱们应该学到点幸福生活的秘诀，就是找到你所喜欢的事，然后找到愿意为你来做这件事的人。Address有点像你合几代人之力辛辛苦苦才弄到的一套新房子，如果不装修，它对你来说的意义也就是你的户口可以从人才中心挪过去了，可以对人说你的

从上节的上节我们已经知道，usb_generic_driver在自己的生命线里，以一己之力将设备的各个接口送给了linux的设备模型，让usb总线的match函数，也就是usb_device_match，在自己的那条驱动链表里为它们寻找一个合适的接口驱动程序。现在让咱们轻声的问一句，这些接口驱动都从哪里来？这就要说到每个玩儿linux的人都会知道的那几个著名的命令insmod，modpro

从上次在几米的向左走向右走遇到usb总线的那个match函数usb_device_match()开始到现在，遇到了设备，遇到了设备驱动，遇到了接口，也遇到了接口驱动，期间还多次遇到usb_device_match()。每个设备也都有一条共同之路，与hub初恋，失身于usb_generic_driver，嫁给了接口驱动，被usb总线保养。设备没有真正自由过，刚开始时在Default状态动弹不得，

关于字符串描述符，前面的前面已经简单描述过了，地位仅次于设备/配置/接口/端点四大描述符，那四大设备必须得支持，而字符串描述符对设备来说则是可选的。这并不是就说字符串描述符不重要，对咱们来说，字符串要比数字亲切的多，提供字符串描述符的设备也要比没有提供的设备亲切的多，不会有人会专门去记前面使用lsusb列出的04b4表示的是Cypress Semiconductor Corp.。一

一个完整的USB系统应该实现上面图里的各个部分，图里主要显示了四个层次，USB物理设备（USB Physical Device）、客户软件（Client SW）、USB系统软件（USB System SW）以及USB Host Controller。Host Controller已经说过了，系统软件就是操作系统里用来支持USB的部分，像咱们的usb core，还有各种设备驱动等等，客户软件么，就是

现在设备的struct usb_device结构体已经准备好了，只是还不怎么饱满，hub接下来就会给它做做整容手术，往里边儿塞点什么，充实一些内容，比如：将设备的状态设置为Powered，也就是加电状态；因为此时还不知道设备支持的速度，于是将设备的speed成员暂时先设置为USB_SPEED_UNKNOWN；设备的级别level当然会被设置为hub的level加上1了；还有为设备能够从hub那里获