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