Linux USB驱动框架分析.docx
《Linux USB驱动框架分析.docx》由会员分享,可在线阅读,更多相关《Linux USB驱动框架分析.docx(30页珍藏版)》请在冰豆网上搜索。
![Linux USB驱动框架分析.docx](https://file1.bdocx.com/fileroot1/2023-1/31/2949d450-20b4-4428-983d-6bb90d783cd3/2949d450-20b4-4428-983d-6bb90d783cd31.gif)
LinuxUSB驱动框架分析
LinuxUSB驱动框架分析
(一)
事实上,Linux的设备驱动都遵循一个惯例——表征驱动程序(用driver更贴切一些,应该称为驱动器比较好吧)的结构体,结构体里面应该包含了驱动程序所需要的所有资源。
用OO的术语来说,就是这个驱动器对象所拥有的属性及成员。
由于Linux的内核用c来编写,所以我们也按照这种结构化的思想来分析代码,但我还是希望从OO的角度来阐述这些细节。
这个结构体的名字有驱动开发人员决定,比如说,鼠标可能有一个叫做mouse_dev的struct,键盘可能由一个keyboard_dev的struct(devfordevice,我们做的只是设备驱动)。
而这次我们来分析一下Linux内核源码中的一个usb-skeleton(就是usb驱动的骨架咯),自然,他定义的设备结构体就叫做usb-skel:
structusb_skel{
structusb_device* udev; /*theusbdeviceforthisdevice*/
structusb_interface*interface; /*theinterfaceforthisdevice*/
structsemaphore limit_sem; /*limitingthenumberofwritesinprogress*/
unsignedchar* bulk_in_buffer; /*thebuffertoreceivedata*/
size_t bulk_in_size; /*thesizeofthereceivebuffer*/
__u8 bulk_in_endpointAddr; /*theaddressofthebulkinendpoint*/
__u8 bulk_out_endpointAddr;/*theaddressofthebulkoutendpoint*/
structkref kref;
};
这里我们得补充说明一下一些USB的协议规范细节。
USB能够自动监测设备,并调用相应的驱动程序处理设备,所以其规范实际上是相当复杂的,幸好,我们不必理会大部分细节问题,因为Linux已经提供相应的解决方案。
就我现在的理解来说,USB的驱动分为两块,一块是USB的bus驱动,这个东西,Linux内核已经做好了,我们可以不管,但我们至少要了解他的功能。
形象得说,USB的bus驱动相当于铺出一条路来,让所有的信息都可以通过这条USB通道到达该到的地方,这部分工作由usb_core来完成。
当设备接到USB接口时,usb_core就检测该设备的一些信息,例如生产厂商ID和产品的ID,或者是设备所属的class、subclass跟protocol,以便确定应该调用哪一个驱动处理该设备。
里面复杂细节我们不用管,我们要做的是另一块工作——usb的设备驱动。
也就是说,我们就等着usb_core告诉我们要工作了,我们才工作。
对于usb规范定义的设备,他们有一个设备的框架,对于开发人员来说,他大概如图所示:
从开发人员的角度看,每一个usb设备有若干个配置(configuration)组成,每个配置又可以有多个接口(interface),每个接口又有多个设置(setting图中没有给出),而接口本身可能没有端点或者多个端点(endpoint)。
USB的数据交换通过端点来进行,主机与各个端点之间建立起单向的管道来传输数据。
而这些接口可以分为四类:
控制(control)用于配置设备、获取设备信息、发送命令或者获取设备的状态报告
中断(interrupt)当USB宿主要求设备传输数据时,中断端点会以一个固定的速率传送少量数据,还用于发送数据到USB设备以控制设备,一般不用于传送大量数据。
批量(bulk)用于大量数据的可靠传输,如果总线上的空间不足以发送整个批量包,它会被分割成多个包传输。
等时(isochronous)大量数据的不可靠传输,不保证数据的到达,但保证恒定的数据流,多用于数据采集。
Linux中用structusb_host_endpoint来描述USB端点,每个usb_host_endpoint中包含一个structusb_endpoint_descriptor结构体,当中包含该端点的信息以及设备自定义的各种信息,这些信息包括:
bEndpointAddress(bforbyte)
8位端点地址,其地址还隐藏了端点方向的信息(之前说过,端点是单向的),可以用掩码USB_DIR_OUT和USB_DIR_IN来确定。
bmAttributes
端点的类型,结合USB_ENDPOINT_XFERTYPE_MASK可以确定端点是USB_ENDPOINT_XFER_ISOC(等时)、USB_ENDPOINT_XFER_BULK(批量)还是USB_ENDPOINT_XFER_INT(中断)。
wMaxPacketSize
端点一次处理的最大字节数。
发送的BULK包可以大于这个数值,但会被分割传送。
bInterval
如果端点是中断类型,该值是端点的间隔设置,以毫秒为单位。
在逻辑上,一个USB设备的功能划分是通过接口来完成的。
比如说一个USB扬声器,可能会包括有两个接口:
一个用于键盘控制,另外一个用于音频流传输。
而事实上,这种设备需要用到不同的两个驱动程序来操作,一个控制键盘,一个控制音频流。
但也有例外,比如蓝牙设备,要求有两个接口,第一用于ACL跟EVENT的传输,另外一个用于SCO链路,但两者通过一个驱动控制。
在Linux上,接口使用structusb_interface来描述,以下是该结构体中比较重要的字段:
structusb_host_interface*altsetting(注意不是usb_interface)
其实据我理解,他应该是每个接口的设置,虽然名字上有点奇怪。
该字段是一个设置的数组(一个接口可以有多个设置),每个usb_host_interface都包含一套由structusb_host_endpoint定义的端点配置。
但这些配置次序是不定的。
unsignednum_altstting
可选设置的数量,即altsetting所指数组的元素个数。
structusb_host_interface*cur_altsetting
当前活动的设置,指向altsetting数组中的一个。
intminor
当捆绑到该接口的USB驱动程序使用USB主设备号时,USBcore分配的次设备号。
仅在成功调用usb_register_dev之后才有效。
除了它可以用structusb_host_config来描述之外,到现在为止,我对配置的了解不多。
而整个USB设备则可以用structusb_device来描述,但基本上只会用它来初始化函数的接口,真正用到的应该是我们之前所提到的自定义的一个结构体。
LinuxUSB驱动框架分析
(二)
好,了解过USB一些规范细节之后,我们现在来看看Linux的驱动框架。
事实上,Linux的设备驱动,特别是这种hotplug的USB设备驱动,会被编译成模块,然后在需要时挂在到内核。
要写一个Linux的模块并不复杂,以一个helloworld为例:
#include
#include
MODULE_LICENSE(“GPL”);
staticinthello_init(void)
{
printk(KERN_ALERT“HelloWorld!
\n”);
return0;
}
staticinthello_exit(void)
{
printk(KERN_ALERT“GOODBYE!
\n”);
}
module_init(hello_init);
module_exit(hello_exit);
这个简单的程序告诉大家应该怎么写一个模块,MODULE_LICENSE告诉内核该模块的版权信息,很多情况下,用GPL或者BSD,或者两个,因为一个私有模块一般很难得到社区的帮助。
module_init和module_exit用于向内核注册模块的初始化函数和模块退出函数。
如程序所示,初始化函数是hello_init,而退出函数是hello_exit。
另外,要编译一个模块通常还需要用到内核源码树种的makefile,所以模块的Makefile可以写成:
ifneq($(KERNELRELEASE),)
obj-m:
=hello.o#usb-dongle.o
else
KDIR:
=/usr/src/linux-headers-$(shelluname-r)
BDIR:
=$(shellpwd)
default:
$(MAKE)-C$(KDIR)M=$(PWD)modules
.PHONY:
clean
clean:
make-C$(KDIR)M=$(BDIR)clean
endif
可以用insmod跟rmmod来验证模块的挂在跟卸载,但必须用root的身份登陆命令行,用普通用户加su或者sudo在Ubuntu上的测试是不行的。
LinuxUSB驱动框架分析(三)
下面分析一下usb-skeleton的源码。
这个范例程序可以在linux-2.6.17/drivers/usb下找到,其他版本的内核程序源码可能有所不同,但相差不大。
大家可以先找到源码看一看,先有个整体印象。
之前已经提到,模块先要向内核注册初始化跟销毁函数:
staticint__initusb_skel_init(void)
{
intresult;
/*registerthisdriverwiththeUSBsubsystem*/
result=usb_register(&skel_driver);
if(result)
err("usb_registerfailed.Errornumber%d",result);
returnresult;
}
staticvoid__exitusb_skel_exit(void)
{
/*deregisterthisdriverwiththeUSBsubsystem*/
usb_deregister(&skel_driver);
}
module_init(usb_skel_init);
module_exit(usb_skel_exit);
MODULE_LICENSE("GPL");
从代码开来,这个init跟exit函数的作用只是用来注册驱动程序,这个描述驱动程序的结构体是系统定义的标准结构structusb_driver,注册和注销的方法很简单,usb_register(struct*usb_driver),usb_deregister(struct*usb_driver)。
那这个结构体需要做些什么呢?
他要向系统提供几个函数入口,跟驱动的名字:
staticstructusb_driverskel_driver={
.name="skeleton",
.probe=skel_probe,
.disconnect=skel_disconnect,
.id_table=skel_table,
};
从代码看来,usb_driver需要初始化四个东西:
模块的名字skeleton,probe函数skel_probe,disconnect函数skel_disconnect,以及id_table。
在解释skel_driver各个成员之前,我们先来看看另外一个结构体。
这个结构体的名字有开发人员自定义,它描述的是该驱动拥有的所有资源及状态:
structusb_skel{
structusb_device*udev;/*theusbdeviceforthisdevice*/
structusb_interface*interface;/*theinterfaceforthisdevice*/
structsemaphorelimit_sem;/*limitingthenumberofwritesinprogress*/
unsignedchar*bulk_in_buffer;/*thebuffertoreceivedata*/
size_tbulk_in_size;/*thesizeofthereceivebuffer*/
__u8bulk_in_endpointAddr;/*theaddressofthebulkinendpoint*/
__u8bulk_out_endpointAddr;/*theaddressofthebulkoutendpoint*/
structkrefkref;
};
我们先来对这个usb_skel作个简单分析,他拥有一个描述usb设备的结构体udev,一个接口interface,用于并发访问控制的semaphore(信号量)limit_sem,用于接收数据的缓冲bulk_in_buffer及其尺寸bulk_in_size,然后是批量输入输出端口地址bulk_in_endpointAddr、bulk_out_endpointAddr,最后是一个内核使用的引用计数器。
他们的作用我们将在后面的代码中看到。
我们再回过头来看看skel_driver。
name用来告诉内核模块的名字是什么,这个注册之后由系统来使用,跟我们关系不大。
id_table用来告诉内核该模块支持的设备。
usb子系统通过设备的productionID和vendorID的组合或者设备的class、subclass跟protocol的组合来识别设备,并调用相关的驱动程序作处理。
我们可以看看这个id_table到底是什么东西:
/*Definethesevaluestomatchyourdevices*/
#defineUSB_SKEL_VENDOR_ID0xfff0
#defineUSB_SKEL_PRODUCT_ID0xfff0
/*tableofdevicesthatworkwiththisdriver*/
staticstructusb_device_idskel_table[]={
{USB_DEVICE(USB_SKEL_VENDOR_ID,USB_SKEL_PRODUCT_ID)},
{}/*Terminatingentry*/
};
MODULE_DEVICE_TABLE(usb,skel_table);
MODULE_DEVICE_TABLE的第一个参数是设备的类型,如果是USB设备,那自然是usb(如果是PCI设备,那将是pci,这两个子系统用同一个宏来注册所支持的设备。
这涉及PCI设备的驱动了,在此先不深究)。
后面一个参数是设备表,这个设备表的最后一个元素是空的,用于标识结束。
代码定义了USB_SKEL_VENDOR_ID是0xfff0,USB_SKEL_PRODUCT_ID是0xfff0,也就是说,当有一个设备接到集线器时,usb子系统就会检查这个设备的vendorID和productID,如果它们的值是0xfff0时,那么子系统就会调用这个skeleton模块作为设备的驱动。
LinuxUSB驱动框架分析(四)
probe是usb子系统自动调用的一个函数,有USB设备接到硬件集线器时,usb子系统会根据productionID和vendorID的组合或者设备的class、subclass跟protocol的组合来识别设备调用相应驱动程序的probe(探测)函数,对于skeleton来说,就是skel_probe。
系统会传递给探测函数一个usb_interface*跟一个structusb_device_id*作为参数。
他们分别是该USB设备的接口描述(一般会是该设备的第0号接口,该接口的默认设置也是第0号设置)跟它的设备ID描述(包括VendorID、ProductionID等)。
probe函数比较长,我们分段来分析这个函数:
dev->udev=usb_get_dev(interface_to_usbdev(interface));
dev->interface=interface;
在初始化了一些资源之后,可以看到第一个关键的函数调用——interface_to_usbdev。
他同uo一个usb_interface来得到该接口所在设备的设备描述结构。
本来,要得到一个usb_device只要用interface_to_usbdev就够了,但因为要增加对该usb_device的引用计数,我们应该在做一个usb_get_dev的操作,来增加引用计数,并在释放设备时用usb_put_dev来减少引用计数。
这里要解释的是,该引用计数值是对该usb_device的计数,并不是对本模块的计数,本模块的计数要由kref来维护。
所以,probe一开始就有初始化kref。
事实上,kref_init操作不单只初始化kref,还将其置设成1。
所以在出错处理代码中有kref_put,它把kref的计数减1,如果kref计数已经为0,那么kref会被释放。
kref_put的第二个参数是一个函数指针,指向一个清理函数。
注意,该指针不能为空,或者kfree。
该函数会在最后一个对kref的引用释放时被调用(如果我的理解不准确,请指正)。
下面是内核源码中的一段注释及代码:
/**
*kref_put-decrementrefcountforobject.
*@kref:
object.
*@release:
pointertothefunctionthatwillcleanuptheobjectwhenthe
*lastreferencetotheobjectisreleased.
*Thispointerisrequired,anditisnotacceptabletopasskfree
*inasthisfunction.
*
*Decrementtherefcount,andif0,callrelease().
*Return1iftheobjectwasremoved,otherwisereturn0.Beware,ifthis
*functionreturns0,youstillcannotcountonthekreffromremainingin
*memory.Onlyusethereturnvalueifyouwanttoseeifthekrefisnow
*gone,notpresent.
*/
intkref_put(structkref*kref,void(*release)(structkref*kref))
{
WARN_ON(release==NULL);
WARN_ON(release==(void(*)(structkref*))kfree);
/*
*ifcurrentcountisone,wearethelastuserandcanreleaseobject
*rightnow,avoidinganatomicoperationon'refcount'
*/
if((atomic_read(&kref->refcount)==1)||
(atomic_dec_and_test(&kref->refcount))){
release(kref);
return1;
}
return0;
}
当我们执行打开操作时,我们要增加kref的计数,我们可以用kref_get,来完成。
所有对structkref的操作都有内核代码确保其原子性。
得到了该usb_device之后,我们要对我们自定义的usb_skel各个状态跟资源作初始化。
这部分工作的任务主要是向usb_skel注册该usb设备的端点。
这里可能要补充以下一些关于usb_interface_descriptor的知识,但因为内核源码对该结构体的注释不多,所以只能靠个人猜测。
在一个usb_host_interface结构里面有一个usb_interface_descriptor叫做desc的成员,他应该是用于描述该interface的一些属性,其中bNumEndpoints是一个8位(bforbyte)的数字,他代表了该接口的端点数。
probe然后遍历所有的端点,检查他们的类型跟方向,注册到usb_skel中。
/*setuptheendpointinformation*/
/*useonlythefirstbulk-inandbulk-outendpoints*/
iface_desc=interface->cur_altsetting;
for(i=0;idesc.bNumEndpoints;++i){
endpoint=&iface_desc->endpoint.desc;
if(!
dev->bulk_in_endpointAddr&&
((endpoint->bEndpointAddress&USB_ENDPOINT_DIR_MASK)==USB_DIR_IN)&&
((endpoint->bmAttributes&USB_ENDPOINT_XFERTYPE_MASK)==USB_ENDPOINT_XFER_BULK)){
/*wefoundabulkinendpoint*/
buffer_size=le16_to_cpu(endpoint->wMaxPacketSize);
dev->bulk_in_size=buffer_size;
dev->bulk_in_endpointAddr=endpoint->bEndpointAddress;
dev->bulk_in_buffer=kmalloc(buffer_size,GFP_KERNEL);
if(!
dev->bulk_in_buffer){
err("Couldnotallocat