Linux设备驱动之USBhub驱动.docx
《Linux设备驱动之USBhub驱动.docx》由会员分享，可在线阅读，更多相关《Linux设备驱动之USBhub驱动.docx（61页珍藏版）》请在冰豆网上搜索。
Linux设备驱动之USBhub驱动
Linux设备驱动之USBhub驱动
Linux设备驱动之USBhub驱动
------------------------------------------
本文系本站原创,欢迎!
请注明出处:
.linux100.org
------------------------------------------
一:
前言
继UHCI的驱动之后,我们对USBControl的运作有了一定的了解.在接下来的分析中,我们对USB设备的驱动做一个全面的分析,我们先从HUB的驱动说起.关于HUB,usb2.0spec上有详细的定义,基于这部份的代码位于linux-2.6.25/drivers/usb/core下,也就是说,这部份代码是位于core下,和具体设备是无关的,因为各厂商的hub都是按照spec的要求来设计的.
二:
UHCI驱动中的roothub
记得在分析UHCI驱动的时候,曾详细分析过roothub的初始化操作.为了分析方便,将代码片段列出如下:
usb_add_hcd（）àusb_alloc_dev（）:
structusb_device*usb_alloc_dev（structusb_device*parent,
structusb_bus*bus,unsignedport1）
{
……
……
//usb_device,内嵌有structdevice结构,对这个结构进行初始化
device_initialize（&dev->dev）;
dev->dev.bus=&usb_bus_type;
dev->dev.type=&usb_device_type;
……
……
}
一看到前面对dev的赋值,根据我们对设备模型的理解,一旦这个device进行注册,就会发生driver和device的匹配过程了.
不过,现在还不是分析这个过程的时候,我们先来看一下,USB子系统中的两种驱动.
三:
USB子系统中的两种驱动
linux-2.6.25/drivers/usb/core/driver.c中,我们可以找到两种registerdriver的方式,分别为usb_register_driver（）和usb_register_device_driver（）.分别来分析一下这两个接口.
usb_register_device_driver（）接口的代码如下:
intusb_register_device_driver（structusb_device_driver*new_udriver,
structmodule*owner）
{
intretval=0;
if（usb_disabled（））
return-ENODEV;
new_udriver->drvwrap.for_devices=1;
new_udriver->drvwrap.driver.name=（char*）new_udriver->name;
new_udriver->drvwrap.driver.bus=&usb_bus_type;
new_udriver->drvwrap.driver.probe=usb_probe_device;
new_udriver->drvwrap.driver.remove=usb_unbind_device;
new_udriver->drvwrap.driver.owner=owner;
retval=driver_register（&new_udriver->drvwrap.driver）;
if（!
retval）{
pr_info（“%s:
registerednewdevicedriver%s\n”,
usbcore_name,new_udriver->name）;
usbfs_update_special（）;
}else{
printk（KERN_ERR“%s:
error%dregisteringdevice““driver%s\n”,
usbcore_name,retval,new_udriver->name）;
}
returnretval;
}
首先,通过usb_disabled（）来判断一下usb是否被禁用,如果被禁用,当然就不必执行下面的流程了,直接退出即可.
从上面的代码,很明显可以看到,structusb_device_driver对structdevice_driver进行了一次封装,我们注意一下这里的赋值操作:
new_udriver->drvwrap.for_devices=1.等等.这些在后面都是用派上用场的.
usb_register_driver（）的代码如下:
intusb_register_driver（structusb_driver*new_driver,structmodule*owner,
constchar*mod_name）
{
intretval=0;
if（usb_disabled（））
return-ENODEV;
new_driver->drvwrap.for_devices=0;
new_driver->drvwrap.driver.name=（char*）new_driver->name;
new_driver->drvwrap.driver.bus=&usb_bus_type;
new_driver->drvwrap.driver.probe=usb_probe_interface;
new_driver->drvwrap.driver.remove=usb_unbind_interface;
new_driver->drvwrap.driver.owner=owner;
new_driver->drvwrap.driver.mod_name=mod_name;
spin_lock_init（&new_driver->dynids.lock）;
INIT_LIST_HEAD（&new_driver->dynids.list）;
retval=driver_register（&new_driver->drvwrap.driver）;
if（!
retval）{
pr_info（“%s:
registerednewinterfacedriver%s\n”,
usbcore_name,new_driver->name）;
usbfs_update_special（）;
usb_create_newid_file（new_driver）;
}else{
printk（KERN_ERR“%s:
error%dregisteringinterface““driver%s\n”,
usbcore_name,retval,new_driver->name）;
}
returnretval;
}
很明显,在这里接口里,将new_driver->drvwrap.for_devices设为了0.而且两个接口的porbe（）函数也不一样.
其实,对于usb_register_driver（）可以看作是usb设备中的接口驱动,而usb_register_device_driver（）是一个单纯的USB设备驱动.
四:
hub的驱动分析
4.1:
usb_bus_type->match（）的匹配过程
usb_bus_type->match（）用来判断驱动和设备是否匹配,它的代码如下:
staticintusb_device_match（structdevice*dev,structdevice_driver*drv）
{
/*整理by.linux100.org*/
//usbdevice的情况
if（is_usb_device（dev））{
/*interfacedriversnevermatchdevices*/
if（!
is_usb_device_driver（drv））
return0;
/*TODO:
Addrealmatchingcode*/
return1;
}
//interface的情况
else{
structusb_interface*intf;
structusb_driver*usb_drv;
conststructusb_device_id*id;
/*整理by.linux100.org*/
if（is_usb_device_driver（drv））
return0;
intf=to_usb_interface（dev）;
usb_drv=to_usb_driver（drv）;
id=usb_match_id（intf,usb_drv->id_table）;
if（id）
return1;
id=usb_match_dynamic_id（intf,usb_drv）;
if（id）
return1;
}
return0;
}
这里的match会区分上面所说的两种驱动,即设备的驱动和接口的驱动.
is_usb_device（）的代码如下:
staticinlineintis_usb_device（conststructdevice*dev）
{
returndev->type==&usb_device_type;
}
很明显,对于roothub来说,这个判断是肯定会满足的.
staticinlineintis_usb_device_driver（structdevice_driver*drv）
{
returncontainer_of（drv,structusbdrv_wrap,driver）->
for_devices;
}
回忆一下,我们在分析usb_register_device_driver（）的时候,不是将new_udriver->drvwrap.for_devices置为了1么?
所以对于usb_register_device_driver（）注册的驱动来说,这里也是会满足的.
因此,对应roothub的情况,从第一个if就会匹配到usb_register_device_driver（）注册的驱动.
对于接口的驱动,我们等遇到的时候再来进行分析.
4.2:
roothub的驱动入口
既然我们知道,roothub会匹配到usb_bus_type->match（）的驱动,那这个驱动到底是什么呢?
我们从usb子系统的初始化开始说起.
在linux-2.6.25/drivers/usb/core/usb.c中.有这样的一段代码:
subsys_initcall（usb_init）;
对于subsys_initcall（）我们已经不陌生了,在很多地方都会遇到它.在系统初始化的时候,会调用到它对应的函数.在这里,即为usb_init（）.
在usb_init（）中,有这样的代码片段:
staticint__initusb_init（void）
{
……
……
retval=usb_register_device_driver（&usb_generic_driver,THIS_MODULE）;
if（!
retval）
gotoout;
……
}
在这里终于看到usb_register_device_driver（）了.usb_generic_driver会匹配到所有usb设备.定义如下:
structusb_device_driverusb_generic_driver={
.name=“usb”,
.probe=generic_probe,
.disconnect=generic_disconnect,
#ifdefCONFIG_PM
.suspend=generic_suspend,
.resume=generic_resume,
#endif
.supports_autosuspend=1,
};
现在是到分析probe（）的时候了.我们这里说的并不是usb_generic_driver中的probe,而是封装在structusb_device_driver中的driver对应的probe函数.
在上面的分析,usb_register_device_driver（）将封装的driver的probe（）函数设置为了usb_probe_device（）.代码如下:
staticintusb_probe_device（structdevice*dev）
{
structusb_device_driver*udriver=to_usb_device_driver（dev->driver）;
structusb_device*udev;
interror=-ENODEV;
dev_dbg（dev,“%s\n”,__FUNCTION__）;
//再次判断dev是否是usbdevice
if（!
is_usb_device（dev））/*Sanitycheck*/
returnerror;
udev=to_usb_device（dev）;
/*TODO:
Addrealmatchingcode*/
/*Thedeviceshouldalwaysappeartobeinuse
*unlessthedriversuportsautosuspend.
*/
//pm_usage_t:
autosuspend计数.如果此计数为1,则不允许autosuspend
udev->pm_usage_t=!
（udriver->supports_autosuspend）;
error=udriver->probe（udev）;
returnerror;
}
首先,可以通过container_of（）将封装的structdevice,structdevice_driver转换为structusb_device和structusb_device_driver.
然后,再执行一次安全检查,判断dev是否是属于一个usbdevice.
在这里,我们首次接触到了hubsuspend.如果不支持suspend（udriver->supports_autosuspend为0）,则udev->pm_usage_t被设为1,也就是说,它不允许设备suspend.否则,将其初始化为0.
最后,正如你所看到的,流程转入到了usb_device_driver->probe（）.
对应到roothub,流程会转入到generic_probe（）.代码如下:
staticintgeneric_probe（structusb_device*udev）
{
interr,c;
/*putdevice-specificfilesintosysfs*/
usb_create_sysfs_dev_files（udev）;
/*Chooseandsettheconfiguration.Thisregisterstheinterfaces
*withthedrivercoreandletsinterfacedriversbindtothem.
*/
if（udev->authorized==0）
dev_err（&udev->dev,“Deviceisnotauthorizedforusage\n”）;
else{
//选择和设定一个配置
c=usb_choose_configuration（udev）;
if（c>=0）{
err=usb_set_configuration（udev,c）;
if（err）{
dev_err（&udev->dev,“can’tsetconfig#%d,error%d\n”,
c,err）;
/*Thisneednotbefatal.Theusercantryto
*setotherconfigurations.*/
}
}
}
/*USBdevicestate==configured...usable*/
usb_notify_add_device（udev）;
return0;
}
usb_create_sysfs_dev_files（）是在sysfs中显示几个属性文件,不进行详细分析,有兴趣的可以结合之前分析的>来看下代码.
usb_notify_add_device（）是有关notify链表的操作,这里也不做详细分析.
至于udev->authorized,在roothub的初始化中,是会将其初始化为1的.后面的逻辑就更简单了.为roothub选择一个配置然后再设定这个配置.
还记得我们在分析roothub的时候,在usb_new_device（）中,会将设备的所有配置都取出来,然后将它们放到了usb_device->config.现在这些信息终于会派上用场了.不太熟悉的,可以看下本站之前有关usb控制器驱动的文档.
Usb2.0spec上规定,对于hub设备,只能有一个config,一个interface,一个endpoint.实际上,在这里,对hub的选择约束不大,反正就一个配置,不管怎么样,选择和设定都是这个配置.
不过,为了方便以后的分析,我们还是跟进去看下usb_choose_configuration（）和usb_set_configuration（）的实现.
实际上,经过这两个函数之后,设备的probe（）过程也就会结束了.
4.2.1:
usb_choose_configuration（）函数分析
usb_choose_configuration（）的代码如下:
//为usbdevice选择一个合适的配置
intusb_choose_configuration（structusb_device*udev）
{
inti;
intnum_configs;
intinsufficient_power=0;
structusb_host_config*c,*best;
best=NULL;
//config数组
c=udev->config;
//config项数
num_configs=udev->descriptor.bNumConfigurations;
//遍历所有配置项
for（i=0;i
structusb_interface_descriptor*desc=NULL;
/*It’spossiblethataconfighasnointerfaces!
*/
//配置项的接口数目
//取配置项的第一个接口
if（c->desc.bNumInterfaces>0）
desc=&c->intf_cache[0]->altsetting->desc;
/*
*HP’sUSBbus-poweredkeyboardhasonlyoneconfiguration
*anditclaimstobeself-powered;otherdevicesmayhave
*similarerrorsintheirdescriptors.Ifthenexttest
*wereallowedtoexecute,suchconfigurationswouldalways
*berejectedandthedeviceswouldnotworkasexpected.
*Inthemeantime,weruntheriskofselectingaconfig
*thatrequiresexternalpoweratatimewhenthatpower
*isn’tavailable.Itseemstobethelesseroftwoevils.
*
*Bugzilla#6448reportsadevicethatappearstocrash
*whenitreceivesaGET_DEVICE_STATUSrequest!
Wedon’t
*haveanyotherwaytotellwhetheradeviceisself-powered,
*butsincewedon’tusethatinformationanywherebuthere,
*thecallhasbeenremoved.
*
*MaybetheGET_DEVICE_STATUScallandthetestbelowcan
*bereinstatedwhendevicefirmwaresbeemorereliable.
*Don’tholdyourbreath.
*/
#if0
/*Ruleoutself-poweredconfigsforabus-powereddevice*/
if（bus_powered&&（c->desc.bmAttributes&
USB_CONFIG_ATT_SELFPOWER））
continue;
#endif
/*
*Thenexttestmaynotbeaseffectiveasitshouldbe.
*Somehubshaveerrorsintheirdescriptor,claiming
*tobeself-poweredwhentheyarereallybus-powered.
*Wewilloverestimatetheamountofcurrentsuchhubs
*makeavailableforeachport.
*
*Thisisafairlybenignsortoffailure.Itwon’t
*causeus
升级会员 