linux usb-skeleton,Linux USB驱动程序(2)----usb-skeleton.c分析

骑猪看日落 2023-01-22 02:51 26阅读 0赞

前文曾经说过这个程序相当于linux调试USB的万能驱动，到底它有什么能耐这么厉害。不会很大吧，统计下：

\[zhh@localhost usb\]$ wc -l usb-skeleton.c

525 usb-skeleton.c

只有525行，500多行的程序，对学习linux的兄弟来说，毛毛雨而已，呵呵。抱着乐观的心情，开始探索之路吧。

先看看注册和注销函数，如下：

static struct usb\_driver skel\_driver = \{

.name ="skeleton",

.probe =skel\_probe,

.disconnect =skel\_disconnect,

.suspend =skel\_suspend,

.resume =skel\_resume,

.pre\_reset =skel\_pre\_reset,

.post\_reset =skel\_post\_reset,

.id\_table =skel\_table,

.supports\_autosuspend = 1,

\};

static int \_\_init usb\_skel\_init(void)

int result;

/\* register this driver with the USB subsystem \*/

result = usb\_register(&skel\_driver);

if (result)

err("usb\_register failed. Error number %d", result);

return result;

static void \_\_exit usb\_skel\_exit(void)

/\* deregister this driver with the USB subsystem \*/

usb\_deregister(&skel\_driver);

module\_init(usb\_skel\_init);

module\_exit(usb\_skel\_exit);

MODULE\_LICENSE("GPL");

简单看下struct usb\_driver结构体

/\*\*

\* struct usb\_driver - identifies USB interface driver to usbcore

\* @name: The driver name should be unique among USB drivers,

\*and should normally be the same as the module name.

指向驱动程序名字的指针。在内核的所有USB驱动程序中它必须是唯一的，通常被设置为和驱动程序模块名相同的名字

\* @probe: Called to see if the driver is willing to manage a particular

\*interface on a device.If it is, probe returns zero and uses

\*usb\_set\_intfdata() to associate driver-specific data with the

\*interface.It may also use usb\_set\_interface() to specify the

\*appropriate altsetting.If unwilling to manage the interface,

\*return -ENODEV, if genuine IO errors occured, an appropriate

\*negative errno value.指向USB驱动程序的探测函数的指针。当USB核心认为它有一个struct usb\_interface可以由该驱动程序处理时，它将调用该函数。USB核心用来判断的指向struct usb\_device\_id的指针也被传递给该函数。如果USB驱动程序确认传递给它的struct usb\_interface，它应该初始化设备然后返回0.如果驱动程序不确认该设备或者发生了错误，它应该返回一个负的错误值。

\* @disconnect: Called when the interface is no longer accessible, usually

\*because its device has been (or is being) disconnected or the

\*driver module is being unloaded.指向USB驱动程序中的断开函数的指针。当struct usb\_interface被从系统中移除或者驱动程序正在从USB核心卸载时，USB核心将调用该函数。

\* @ioctl: Used for drivers that want to talk to userspace through

\*the "usbfs" filesystem.This lets devices provide ways to

\*expose information to user space regardless of where they

\*do (or don't) show up otherwise in the filesystem.

\* @suspend: Called when the device is going to be suspended by the system.

\* @resume: Called when the device is being resumed by the system.

\* @reset\_resume: Called when the suspended device has been reset instead

\*of being resumed.

\* @pre\_reset: Called by usb\_reset\_device() when the device

\*is about to be reset.

\* @post\_reset: Called by usb\_reset\_device() after the device

\*has been reset

\* @id\_table: USB drivers use ID table to support hotplugging.

\*Export this with MODULE\_DEVICE\_TABLE(usb,...).This must be set

\*or your driver's probe function will never get called.

\* @dynids: used internally to hold the list of dynamically added device

\*ids for this driver.

\* @drvwrap: Driver-model core structure wrapper.

\* @no\_dynamic\_id: if set to 1, the USB core will not allow dynamic ids to be

\*added to this driver by preventing the sysfs file from being created.

\* @supports\_autosuspend: if set to 0, the USB core will not allow autosuspend

\*for interfaces bound to this driver.

\* @soft\_unbind: if set to 1, the USB core will not kill URBs and disable

\*endpoints before calling the driver's disconnect method.

\* USB interface drivers must provide a name, probe() and disconnect()

\* methods, and an id\_table.Other driver fields are optional.

\* The id\_table is used in hotplugging.It holds a set of descriptors,

\* and specialized data may be associated with each entry.That table

\* is used by both user and kernel mode hotplugging support.

\* The probe() and disconnect() methods are called in a context where

\* they can sleep, but they should avoid abusing the privilege.Most

\* work to connect to a device should be done when the device is opened,

\* and undone at the last close.The disconnect code needs to address

\* concurrency issues with respect to open() and close() methods, as

\* well as forcing all pending I/O requests to complete (by unlinking

\* them as necessary, and blocking until the unlinks complete).

\*/

struct usb\_driver \{

const char \*name;

int (\*probe) (struct usb\_interface \*intf,

const struct usb\_device\_id \*id);

void (\*disconnect) (struct usb\_interface \*intf);

int (\*ioctl) (struct usb\_interface \*intf, unsigned int code,

void \*buf);

int (\*suspend) (struct usb\_interface \*intf, pm\_message\_t message);

int (\*resume) (struct usb\_interface \*intf);

int (\*reset\_resume)(struct usb\_interface \*intf);

int (\*pre\_reset)(struct usb\_interface \*intf);

int (\*post\_reset)(struct usb\_interface \*intf);

const struct usb\_device\_id \*id\_table;

struct usb\_dynids dynids;

struct usbdrv\_wrap drvwrap;

unsigned int no\_dynamic\_id:1;

unsigned int supports\_autosuspend:1;

unsigned int soft\_unbind:1;

\};

创建一个有效的struct usb\_driver结构体只需要初始化五个字段：

static struct usb\_driver skel\_driver = \{

.owner = THIS\_MODULE,

.name ="skeleton",

.probe =skel\_probe,

.disconnect =skel\_disconnect,

.id\_table =skel\_table,

\};

usb-skeleton.c中定义的结构体就是多加了几个字段，可能眼尖的兄弟会发现貌似有2个问题：

(1)owner字段呢，怎么没有了？别急，看看usb\_skel\_init()函数里面的

result = usb\_register(&skel\_driver);

而usb\_register的定义

static inline int usb\_register(struct usb\_driver \*driver)

return usb\_register\_driver(driver, THIS\_MODULE, KBUILD\_MODNAME);

不用进去函数里面，我们都知道owner字段肯定是没问题了。这个函数实现的功能就不多说了。

(2)struct device\_driver driver在哪里呢？没有它，怎么可能把驱动关联到总线上去？

struct usb\_driver里面有这么一个字段struct usbdrv\_wrap drvwrap;

定义如下：

/\*\*

\* struct usbdrv\_wrap - wrapper for driver-model structure

\* @driver: The driver-model core driver structure.

\* @for\_devices: Non-zero for device drivers, 0 for interface drivers.

\*/

struct usbdrv\_wrap \{

struct device\_driver driver;

int for\_devices;

\};

这个USB比较复杂，因此呢，又多定义了这么一个结构体，0代表USB接口驱动，非0代表USB设备驱动。

fudan\_abc大虾们已经把这块说的非常通俗易懂了，就跟着他们的步伐前进吧。前面已经说过一个有效的struct usb\_driver结构体只需要5个字段，owner是用来给模块计数的，每个模块都这么用，赋值总是THIS\_MODULE,而name就是这个模块的名字，usb core会处理它。因此，我们的重点是probe,disconnect与id\_table.

首先亮相的是id\_table，它到底有什么作用呢？下面2段直接引用fudan\_abc大虾们的原文。

“我们说过,一个device只能绑定一个driver,但driver并非只能支持一种设备,道理很简单,比如我有两块U盘,那么我可以一起都插入,但是我只需要加载一个模块,usb-storage,没听说过插入两块U盘就得加载两次驱动程序的,除非这两块U盘本身就得使用不同的驱动程序.也正是因为一个模块可以被多个设备共用,才会有模块计数这么一个说法.

ok,既然一个driver可以支持多个device,那么当发现一个device的时候,如何知道哪个driver才是她的Mr.Right呢?这就是id\_table的用处,让每一个struct usb\_driver准备一张表,里边注明该driver支持哪些设备,这总可以了吧.如果你这个设备属于这张表里的,那么ok,绑定吧,如果不属于这张表里的,那么不好意思,您请便.哪凉快上哪去.”

说到这里，我们不得不看看struct usb\_device\_id的定义了

/\*

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

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

\* Declare the table as a MODULE\_DEVICE\_TABLE.

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

\* Use the driver\_info field for each match to hold information tied

\* to that match:device quirks, etc.

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

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

\*/

/\*\*

\* struct usb\_device\_id - identifies USB devices for probing and hotplugging

\* @match\_flags: Bit mask controlling of the other fields are used to match

\*against new devices.Any field except for driver\_info may be used,

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

\*This is usually set by a USB\_DEVICE\_\*() macro, which sets all

\*other fields in this structure except for driver\_info.

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

\*by the USB forum to its members.

\* @idProduct: Vendor-assigned product ID.

\* @bcdDevice\_lo: Low end of range of vendor-assigned product version numbers.

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

\*a range consisting of a single device.

\* @bcdDevice\_hi: High end of version number range.The range of product

\*versions is inclusive.

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

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

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

\*the interfaces on a devices.

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

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

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

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

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

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

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

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

\* @driver\_info: Holds information used by the driver.Usually it holds

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

\*device flags.

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

\* USB\_DEVICE(), or similar macros designed for that purpose.

\* They will then export it to userspace using MODULE\_DEVICE\_TABLE(),

\* and provide it to the USB core through their usb\_driver structure.

\* See the usb\_match\_id() function for information about how matches are

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

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

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

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

\* matches towards the beginning of your table, so that driver\_info can

\* record quirks of specific products.

\*/

struct usb\_device\_id \{

/\* which fields to match against? \*/

\_\_u16;

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

\_\_u16idVendor;

\_\_u16idProduct;

\_\_u16bcdDevice\_lo;

\_\_u16bcdDevice\_hi;

/\* Used for device class matches \*/

\_\_u8bDeviceClass;

\_\_u8bDeviceSubClass;

\_\_u8bDeviceProtocol;

/\* Used for interface class matches \*/

\_\_u8bInterfaceClass;

\_\_u8bInterfaceSubClass;

\_\_u8bInterfaceProtocol;

/\* not matched against \*/

kernel\_ulong\_tdriver\_info;

\};

相信对USB协议熟悉的兄弟对大部分字段都不会陌生，这里就简要说明下USB协议里面没有的字段，也是非常重要的字段。

match\_flags：控制结构体中其他字段的位掩码，被用来匹配新设备，当然driver\_info字段不包括在里面了。如下面要提到的skel\_table数组，只要匹配VID和PID就认为找到新设备了，就是在这个字段设置的。

从struct usb\_driver skel\_driver的定义中知道，它所支持的USB设备的列表数组为skel\_table，看看定义

/\* table of devices that work with this driver \*/

static struct usb\_device\_id skel\_table \[\] = \{

\{ USB\_DEVICE(USB\_SKEL\_VENDOR\_ID, USB\_SKEL\_PRODUCT\_ID) \},

\{ \}/\* Terminating entry \*/

\};

这里不啰唆了，只要从设备的VID和PID和这里的一致，usb-skeleton就是它的驱动了，也就是以前说的linux万能调试驱动，O(∩\_∩)O

linux usb-skeleton,Linux USB驱动程序(2)----usb-skeleton.c分析

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 linux 内核 usb驱动分析

相关 linux usb-skeleton,Linux USB驱动程序(2)----usb-skeleton.c分析

相关 linux 41852端口,Linux USB驱动框架分析(1)

相关 Linux 驱动程序 USB控制

相关 USB驱动程序之USB设备驱动程序1简单编写

相关 USB驱动程序之USB设备驱动程序2鼠标用作键盘学习笔记

相关 USB驱动程序之USB总线驱动程序学习笔记

相关 Linux-USB总线驱动分析

相关（二）USB驱动程序_USB设备驱动（Host）

相关（一）USB驱动程序_USB基础知识