Linux USB技术深度探索：从入门到精通

4星 · 超过85%的资源需积分: 23 143 浏览量更新于2024-07-28 收藏 1.18MB PDF 举报

"usb源码详析" 这本资料主要涵盖了USB（通用串行总线）技术在Linux系统中的实现和应用，是针对初学者和专业学生深入理解USB内核驱动和设备驱动开发的重要读物。作者通过幽默风趣的语言和生动的比喻，详细解析了USB协议、Linux内核中的USB子系统、设备驱动程序以及相关的数据结构和通信机制。书中首先介绍了USB技术的基本概念，并以小故事的形式引入，使得复杂的技术原理变得易于理解。在"MAKEFILE不是MAKELOVE"章节中，作者讲解了构建和编译USB驱动的Makefile配置过程，强调了模块化在Linux系统中的重要性。接着，书中的"变态的模块机制"探讨了Linux内核中的模块加载和卸载机制，以及USB设备如何与主机通信。在"总线,设备,和驱动"上下篇中，作者详细阐述了USB架构，包括总线、设备和驱动之间的关系，以及它们如何协同工作。"我是谁的他?"章节则进一步深入到USB设备识别和枚举的过程。"从协议中来,到协议中去"系列章节深入到USB协议的细节，包括控制传输、批量传输、中断传输和异步传输等不同类型的传输方式。书中的"梦开始的地方"和"设备花名册"章节分别介绍了USB设备的初始化过程和设备描述符的解析。"冰冻三尺非一日之寒"至"冬天来了,春天还会远吗?"章节逐步揭示了USB驱动的编写步骤和调试技巧，特别是对USB设备与主机间的数据交换进行了详细解读。 "通往春天的管道"章节讲解了USB管道（pipe）的概念，这是USB通信的基础。"传说中的URB（USB请求块）"章节则分析了URB在USB设备驱动中的核心作用，它是设备与内核通信的桥梁。"心锁"章节可能涉及到了同步和互斥机制，确保USB操作的正确性和安全性。接下来的章节如"第一次亲密接触"系列，详细介绍了控制传输的实现，以及"将控制传输进行到底"，说明了控制传输在USB通信中的关键地位。"横空出世的SCSI"章节讨论了USB与SCSI（小型计算机系统接口）的关系，特别是USB存储设备如何通过SCSI层与主机交互。 "谁是最变态的结构体"和"SCSI数据结构-像雾像雨又像风"等章节深入到了SCSI命令的包装和解包过程，以及相关的数据结构设计。"彼岸花的传说"系列章节可能是对USB设备特殊功能或高级特性的探讨，比如异常处理和优化策略。这份资料全面覆盖了USB技术的各个方面，从基础理论到实际操作，再到内核源码的分析，为读者提供了一个深入了解和实践USB驱动开发的完整框架。无论是对USB设备驱动感兴趣的初学者还是寻求提高的专业人士，都能从中获益匪浅。

232 struct usb_driver usb_storage_driver = {

233 .owner = THIS_MODULE,

234 .name = "usb-storage",

235 .probe = storage_probe,

236 .disconnect = storage_disconnect,

237 .id_table = storage_usb_ids,

238 };

可以看到这里定义了一个 struct usb_driver 的结构体变量,usb_storage_driver,关于 usb_driver 我们

上节已经说过了,当时主要说的是其中的成员 driver,而眼下要讲的则是另外几个成员.首先,.owner

和.name 这两个没啥好多说的,owner 这玩艺是用来给模块计数的,每个模块都这么用,赋值总是

THIS_MODULE,而 name 就是这个模块的名字,usb core会处理它,所以如果这个模块正常被加载了的话,

使用 lsmod 命令能看到一个叫做 usb-storage 的模块名.重点要讲一讲,.probe 和.disconnect 以及这个

id_table.

我是谁的他?

probe,disconnect,id_table,这三个咚咚中首先要登场亮相的是 id_table,它是干嘛用的呢?

我们说过,一个 device 只能绑定一个 driver,但 driver并非只能支持一种设备,道理很简单,比如

我有两块 U盘,那么我可以一起都插入,但是我只需要加载一个模块,usb-storage,没听说过插入

两块 U 盘就得加载两次驱动程序的,除非这两块 U 盘本身就得使用不同的驱动程序.也正是因为

一个模块可以被多个设备共用,才会有模块计数这么一个说法.

ok,既然一个 driver可以支持多个 device,那么当发现一个 device的时候,如何知道哪个 driver

才是她的 Mr.Right 呢?这就是 id_table 的用处,让每一个 struct usb_driver 准备一张表,里边

注明该 driver支持哪些设备,这总可以了吧.如果你这个设备属于这张表里的,那么 ok,绑定吧,如

果不属于这张表里的,那么不好意思,您请便.哪凉快上哪去.

来自 struct usb_driver 中的 id_table,

const struct usb_device_id *id_table;

实际上是一个指针,一个 struct usb_device_id 结构体的指针,当然赋了值以后就是代表一个数

组名了,正如我们在定义 struct usb_driver usb_storage_driver 中所赋的值那

样,.id_table=storage_usb_ids,那好,我们来看一下 usb_device_id 这究竟是怎样一个结构

体.

struct usb_device_id 来自 include/linux/mod_devicetable.h,

40 /*

41 * Device table entry for "new style" table-driven USB drivers.

42 * User mode code can read these tables to choose which modules to load.

43 * Declare the table as a MODULE_DEVICE_TABLE.

44 *

45 * A probe() parameter will point to a matching entry from this table.

46 * Use the driver_info field for each match to hold information tied

47 * to that match: device quirks, etc.

48 *

49 * Terminate the driver's table with an all-zeroes entry.

50 * Use the flag values to control which fields are compared.

51 */

53 /**

54 * struct usb_device_id - identifies USB devices for probing and hotplugging

55 * @match_flags: Bit mask controlling of the other fields are used to match

56 * against new devices. Any field except for driver_info may be used,

57 * although some only make sense in conjunction with other fields.

58 * This is usually set by a USB_DEVICE_*() macro, which sets all

59 * other fields in this structure except for driver_info.

60 * @idVendor: USB vendor ID for a device; numbers are assigned

61 * by the USB forum to its members.

62 * @idProduct: Vendor-assigned product ID.

63 * @bcdDevice_lo: Low end of range of vendor-assigned product version

numbers.

64 * This is also used to identify individual product versions, for

65 * a range consisting of a single device.

66 * @bcdDevice_hi: High end of version number range. The range of product

67 * versions is inclusive.

68 * @bDeviceClass: Class of device; numbers are assigned

69 * by the USB forum. Products may choose to implement classes,

70 * or be vendor-specific. Device classes specify behavior of all

71 * the interfaces on a devices.

72 * @bDeviceSubClass: Subclass of device; associated with bDeviceClass.

73 * @bDeviceProtocol: Protocol of device; associated with bDeviceClass.

74 * @bInterfaceClass: Class of interface; numbers are assigned

75 * by the USB forum. Products may choose to implement classes,

76 * or be vendor-specific. Interface classes specify behavior only

77 * of a given interface; other interfaces may support other classes.

78 * @bInterfaceSubClass: Subclass of interface; associated with bInterfaceClass.

79 * @bInterfaceProtocol: Protocol of interface; associated with bInterfaceClass.

80 * @driver_info: Holds information used by the driver. Usually it holds

81 * a pointer to a descriptor understood by the driver, or perhaps

82 * device flags.

83 *

84 * In most cases, drivers will create a table of device IDs by using

85 * USB_DEVICE(), or similar macros designed for that purpose.

86 * They will then export it to userspace using MODULE_DEVICE_TABLE(),

87 * and provide it to the USB core through their usb_driver structure.

88 *

89 * See the usb_match_id() function for information about how matches are

90 * performed. Briefly, you will normally use one of several macros to help

91 * construct these entries. Each entry you provide will either identify

92 * one or more specific products, or will identify a class of products

93 * which have agreed to behave the same. You should put the more specific

94 * matches towards the beginning of your table, so that driver_info can

95 * record quirks of specific products.

96 */

97 struct usb_device_id {

98 /* which fields to match against? */

99 __u16 match_flags;

100

101 /* Used for product specific matches; range is inclusive */

102 __u16 idVendor;

103 __u16 idProduct;

104 __u16 bcdDevice_lo;

105 __u16 bcdDevice_hi;

106

107 /* Used for device class matches */

108 __u8 bDeviceClass;

109 __u8 bDeviceSubClass;

110 __u8 bDeviceProtocol;

111

112 /* Used for interface class matches */

113 __u8 bInterfaceClass;

114 __u8 bInterfaceSubClass;

115 __u8 bInterfaceProtocol;

116

117 /* not matched against */

118 kernel_ulong_t driver_info;

119 };

实际上这个结构体对每一个 usb设备来说,就相当于是她的身份证,记录了她的一些基本信息,通常我们的身

份证上会记录我们的姓名,性别,出生年月,户口地址等等,而 usb 设备她也有她需要记录的信息,以区分她和

别的 usb 设备,比如 Vendor-厂家,Product-产品,以及其他一些比如产品编号,产品的类别,遵循的协议,这

些都会在 usb 的规范里边找到对应的冬冬.暂且先不细说.

于是我们知道,一个 usb_driver 会把它的这张 id 表去和每一个 usb 设备的实际情况进行比较,如果该设备

的实际情况和这张表里的某一个 id相同,准确地说,只有这许多特征都吻合,才能够把一个 usb device 和这

个 usb driver 进行绑定,这些特征哪怕差一点也不行.就像我们每个人都是一道弧,都在不停寻找能让彼此

嵌成完整的圆的另一道弧,事实却是,每个人对∏(PI)的理解不尽相同,而圆心能否重合,或许只有痛过才知

道.差之毫厘,失之交臂.

那么 usb 设备的实际情况是什么时候建立起来的?嗯,在介绍.probe 指针之前有必要先谈一谈另一个数据

结构了,她就是 struct usb_device.

从协议中来,到协议中去(上)

在 struct usb_driver 中,.probe 和.disconnect 的原型如下:

int (*probe) (struct usb_interface *intf,const struct usb_device_id *id);

void (*disconnect) (struct usb_interface *intf);

我们来看其中的参数,struct usb_device_id 这个不用说了,刚才已经介绍过,那么 struct usb_interface

从何而来?还是让我们先从 struct usb_device 说起.

我们知道每一个 device 对应一个 struct device 结构体变量,但是 device 不可能是万能的,生命是多样性

的,就像我们可以用"人"来统称全人类,但是分的细一点,又有男人和女人的区别,那么 device 也一样,由于

有各种各样的设备,于是又出来了更多的词汇(数据结构),比如针对 usb 设备,开发者们设计了一个叫做

struct usb_device 的结构体.她定义于 include/linux/usb.h,

294 /*

295 * struct usb_device - kernel's representation of a USB device

296 *

297 * FIXME: Write the kerneldoc!

298 *

299 * Usbcore drivers should not set usbdev->state directly. Instead use

300 * usb_set_device_state().

301 */

302 struct usb_device {

303 int devnum; /* Address on USB bus */

304 char devpath [16]; /* Use in messages: /port/port/... */

305 enum usb_device_state state; /* configured, not attached, etc */

306 enum usb_device_speed speed; /* high/full/low (or error) */

307

308 struct usb_tt *tt; /* low/full speed dev, highspeed hub */

309 int ttport; /* device port on that tt hub */

310

311 struct semaphore serialize;

312

313 unsigned int toggle[2]; /* one bit for each endpoint ([0] = IN, [1] =

OUT) */

314 int epmaxpacketin[16]; /* INput endpoint specific maximums */

315 int epmaxpacketout[16]; /* OUTput endpoint specific maximums

316

317 struct usb_device *parent; /* our hub, unless we're the root */

318 struct usb_bus *bus; /* Bus we're part of */

319

320 struct device dev; /* Generic device interface */

321

322 struct usb_device_descriptor descriptor;/* Descriptor */

323 struct usb_host_config *config; /* All of the configs */

324 struct usb_host_config *actconfig;/* the active configuration */

325

326 char **rawdescriptors; /* Raw descriptors for each config */

327

328 int have_langid; /* whether string_langid is valid yet */

329 int string_langid; /* language ID for strings */

330

331 void *hcpriv; /* Host Controller private data */

332

333 struct list_head filelist;

334 struct dentry *usbfs_dentry; /* usbfs dentry entry for the device */

335

336 /*

337 * Child devices - these can be either new devices

338 * (if this is a hub device), or different instances

339 * of this same device.

340 *

341 * Each instance needs its own set of data structures.

342 */

343

344 int maxchild; /* Number of ports if hub */

345 struct usb_device *children[USB_MAXCHILDREN];

346 };

347 #define to_usb_device(d) container_of(d, struct usb_device, dev)

看起来很复杂的一个数据结构,不过我们目前不需要去理解她的每一个成员,不过我们可以看到,其中有一个

成员 struct device dev,没错,这就是前面说的那个属于每个设备的 struct device 结构体变量.

实际上,U 盘驱动里边并不会直接去处理这个结构体,因为对于一个 U 盘来说,她就是对应这么一个 struct

usb_device 的变量,这个变量由 usb core 负责申请和赋值.但是我们需要记住这个结构体变量,因为日后

我们调用 usb core 提供的函数的时候,会把这个变量作为参数传递上去,因为很简单,要和 usb core 交流,

总得让人家知道我们是谁吧,比如后来要调用的一个函数,usb_buffer_alloc,它就需要这个参数.

而对 U 盘设备驱动来说,比这个 struct usb_device 更重要的数据结构是,struct usb_interface.走到这

一步,我们不得不去了解一点 usb 设备的规范了,或者专业一点说,usb 协议.因为我们至少要知道什么是

usb interface.

从协议中来,到协议中去(中)

星爷说,人有人他妈,妖有妖他妈.说的就是任何事物都有其要遵守的规矩.usb 设备要遵循的就是 usb 协

议. 不管是软件还是硬件,在设计的伊始,总是要参考 usb协议.怎么设计硬件,如何编写软件,不看 usb协议,

谁也不可能凭空想象出来.毕竟不是写小说,有几人能像海岩那样,光凭想象就能写出便衣警察,永不瞑目,玉

观音这些经典的爱情加案情的作品来呢.

剩余200页未读，继续阅读

xiniily

粉丝: 0
资源: 9

Linux USB技术深度探索：从入门到精通

开发Linux端USB驱动程序，

Java并发编程学习之ThreadLocal源码详析

关于Redis网络模型的源码详析

Spring Security架构以及源码详析

Java基于JDK 1.8的LinkedList源码详析

Java并发编程学习之Unsafe类与LockSupport类源码详析

Linux USB源码探索之旅

Linux USB源码深度解析：设备通信奥秘

SpringBoot教学资源库毕业设计详析与源码

Delphi编程规范详析：从源码到设计

最新资源