欢迎进入Linux社区论坛，与200万技术人员互动交流 >>进入
一：前言
继UHCI的驱动之后，我们对USB Control的运作有了一定的了解。在接下来的分析中，我们对USB设备的驱动做一个全面的分析，我们先从HUB的驱动说起。关于HUB,usb2.0 spec上有详细的定义，基于这部份的代码位于linux-2.6.25/drivers/usb/core下，也就是说，这部份代码是位于core下，和具体设备是无关的，因为各厂商的hub都是按照spec的要求来设计的。
二：UHCI驱动中的root hub
记得在分析UHCI驱动的时候，曾详细分析过root hub的初始化操作。为了分析方便，将代码片段列出如下：
usb_add_hcd（） à usb_alloc_dev（）：
struct usb_device *usb_alloc_dev（struct usb_device *parent,
struct usb_bus *bus, unsigned port1）
{
……
……
//usb_device,内嵌有struct device结构，对这个结构进行初始化
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中，我们可以找到两种register driver的方式，分别为usb_register_driver（）和usb_register_device_driver（）。分别来分析一下这两个接口。
usb_register_device_driver（）接口的代码如下：
int usb_register_device_driver（struct usb_device_driver *new_udriver,
struct module *owner）
{
int retval = 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: registered new device driver %s\n”,
usbcore_name, new_udriver->name）；
usbfs_update_special（）；
} else {
printk（KERN_ERR “%s: error %d registering device “
” driver %s\n”,
usbcore_name, retval, new_udriver->name）；
}
return retval;
}
首先，通过usb_disabled（）来判断一下usb是否被禁用，如果被禁用，当然就不必执行下面的流程了，直接退出即可。
从上面的代码，很明显可以看到， struct usb_device_driver 对struct device_driver进行了一次封装，我们注意一下这里的赋值操作：new_udriver->drvwrap.for_devices = 1.等等。这些在后面都是用派上用场的。
usb_register_driver（）的代码如下：
int usb_register_driver（struct usb_driver *new_driver, struct module *owner,
const char *mod_name）
{
int retval = 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: registered new interface driver %s\n”,
usbcore_name, new_driver->name）；
usbfs_update_special（）；
usb_create_newid_file（new_driver）；
} else {
printk（KERN_ERR “%s: error %d registering interface “
” driver %s\n”,
usbcore_name, retval, new_driver->name）；
}
return retval;
}
很明显，在这里接口里，将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（）用来判断驱动和设备是否匹配，它的代码如下：
static int usb_device_match（struct device *dev, struct device_driver *drv）
{
/* devices and interfaces are handled separately */
//usb device的情况
if （is_usb_device（dev）） {
/* interface drivers never match devices */
if （！is_usb_device_driver（drv））
return 0;
/* TODO: Add real matching code */
return 1;
}
//interface的情况
else {
struct usb_interface *intf;
struct usb_driver *usb_drv;
const struct usb_device_id *id;
/* device drivers never match interfaces */
if （is_usb_device_driver（drv））
return 0;
intf = to_usb_interface（dev）；
usb_drv = to_usb_driver（drv）；
id = usb_match_id（intf, usb_drv->id_table）；
if （id）
return 1;
id = usb_match_dynamic_id（intf, usb_drv）；
if （id）
return 1;
}
return 0;
}
这里的match会区分上面所说的两种驱动，即设备的驱动和接口的驱动。
is_usb_device（）的代码如下：
static inline int is_usb_device（const struct device *dev）
{
return dev->type == &usb_device_type;
}
很明显，对于root hub来说，这个判断是肯定会满足的。
static inline int is_usb_device_driver（struct device_driver *drv）
{
return container_of（drv, struct usbdrv_wrap, driver）->
for_devices;
}
回忆一下，我们在分析usb_register_device_driver（）的时候，不是将new_udriver->drvwrap.for_devices置为了1么？所以对于usb_register_device_driver（）注册的驱动来说，这里也是会满足的。
因此，对应root hub的情况，从第一个if就会匹配到usb_register_device_driver（）注册的驱动。
对于接口的驱动，我们等遇到的时候再来进行分析。
4.2:root hub的驱动入口
既然我们知道，root hub会匹配到usb_bus_type->match（）的驱动，那这个驱动到底是什么呢？我们从usb子系统的初始化开始说起。
在linux-2.6.25/drivers/usb/core/usb.c中。有这样的一段代码：
subsys_initcall（usb_init）；
对于subsys_initcall（）我们已经不陌生了，在很多地方都会遇到它。在系统初始化的时候，会调用到它对应的函数。在这里，即为usb_init（）。
在usb_init（）中，有这样的代码片段：
static int __init usb_init（void）
{
……
……
1
if （！retval）
goto out;
……
}
在这里终于看到usb_register_device_driver（）了。 usb_generic_driver会匹配到所有usb 设备。定义如下：
struct usb_device_driver usb_generic_driver = {
.name = “usb”,
.probe = generic_probe,
.disconnect = generic_disconnect,
#ifdef CONFIG_PM
.suspend = generic_suspend,
.resume = generic_resume,
#endif
.supports_autosuspend = 1,
};
现在是到分析probe（）的时候了。我们这里说的并不是usb_generic_driver中的probe,而是封装在struct usb_device_driver中的driver对应的probe函数。
在上面的分析， usb_register_device_driver（）将封装的driver的probe（）函数设置为了usb_probe_device（）。代码如下：
static int usb_probe_device（struct device *dev）
{
struct usb_device_driver *udriver = to_usb_device_driver（dev->driver）；
struct usb_device *udev;
int error = -ENODEV;
dev_dbg（dev, “%s\n”, __FUNCTION__）；
//再次判断dev是否是usb device
if （！is_usb_device（dev）） /* Sanity check */
return error;
udev = to_usb_device（dev）；
/* TODO: Add real matching code */
/* The device should always appear to be in use
* unless the driver suports autosuspend.
*/
//pm_usage_cnt: autosuspend计数。如果此计数为1,则不允许autosuspend
udev->pm_usage_cnt = !（udriver->supports_autosuspend）；
error = udriver->probe（udev）；
return error;
}
首先，可以通过container_of（）将封装的struct device, struct device_driver转换为struct usb_device和struct usb_device_driver.
然后，再执行一次安全检查，判断dev是否是属于一个usb device.
在这里，我们首次接触到了hub suspend.如果不支持suspend（udriver->supports_autosuspend为0），则udev->pm_usage_cnt被设为1,也就是说，它不允许设备suspend.否则，将其初始化为0.
最后，正如你所看到的，流程转入到了usb_device_driver->probe（）。
对应到root hub,流程会转入到generic_probe（）。代码如下：
static int generic_probe（struct usb_device *udev）
{
int err, c;
/* put device-specific files into sysfs */
usb_create_sysfs_dev_files（udev）；
/* Choose and set the configuration. This registers the interfaces
* with the driver core and lets interface drivers bind to them.
*/
if （udev->authorized == 0）
dev_err（&udev->dev, “Device is not authorized for usage\n”）；
else {
//选择和设定一个配置
c = usb_choose_configuration（udev）；
if （c >= 0） {
err = usb_set_configuration（udev, c）；
if （err） {
dev_err（&udev->dev, “can’t set config #%d, error %d\n”,
c, err）；
/* This need not be fatal. The user can try to
* set other configurations. */
}
}
}
/* USB device state == configured … usable */
usb_notify_add_device（udev）；
return 0;
}
usb_create_sysfs_dev_files（）是在sysfs中显示几个属性文件，不进行详细分析，有兴趣的可以结合之前分析的《linux设备模型详解》来看下代码。
usb_notify_add_device（）是有关notify链表的操作，这里也不做详细分析。
至于udev->authorized,在root hub的初始化中，是会将其初始化为1的。后面的逻辑就更简单了。为root hub 选择一个配置然后再设定这个配置。
还记得我们在分析root hub的时候，在usb_new_device（）中，会将设备的所有配置都取出来，然后将它们放到了usb_device-> config.现在这些信息终于会派上用场了。不太熟悉的，可以看下本站之前有关usb控制器驱动的文档。
Usb2.0 spec上规定，对于hub设备，只能有一个config,一个interface,一个endpoint.实际上，在这里，对hub的选择约束不大，反正就一个配置，不管怎么样，选择和设定都是这个配置。
不过，为了方便以后的分析，我们还是跟进去看下usb_choose_configuration（）和usb_set_configuration（）的实现。
实际上，经过这两个函数之后，设备的probe（）过程也就会结束了。
4.2.1:usb_choose_configuration（）函数分析
usb_choose_configuration（）的代码如下：
//为usb device选择一个合适的配置
int usb_choose_configuration（struct usb_device *udev）
{
int i;
int num_configs;
int insufficient_power = 0;
struct usb_host_config *c, *best;
best = NULL;
//config数组
c = udev->config;
//config项数
num_configs = udev->descriptor.bNumConfigurations;
//遍历所有配置项
for （i = 0; i < num_configs; （i++, c++）） {
struct usb_interface_descriptor *desc = NULL;
/* It’s possible that a config has no interfaces! */
//配置项的接口数目
//取配置项的第一个接口
if （c->desc.bNumInterfaces > 0）
desc = &c->intf_cache[0]->altsetting->desc;
/*
* HP’s USB bus-powered keyboard has only one configuration
* and it claims to be self-powered; other devices may have
* similar errors in their descriptors. If the next test
* were allowed to execute, such configurations would always
* be rejected and the devices would not work as expected.
* In the meantime, we run the risk of selecting a config
* that requires external power at a time when that power
* isn’t available. It seems to be the lesser of two evils.
*
* Bugzilla #6448 reports a device that appears to crash
* when it receives a GET_DEVICE_STATUS request! We don’t
* have any other way to tell whether a device is self-powered,
* but since we don’t use that information anywhere but here,
* the call has been removed.
*
* Maybe the GET_DEVICE_STATUS call and the test below can
* be reinstated when device firmwares become more reliable.
* Don’t hold your breath.
*/
#if 0
/* Rule out self-powered configs for a bus-powered device */
if （bus_powered && （c->desc.bmAttributes &
USB_CONFIG_ATT_SELFPOWER））
continue;
#endif
/*
* The next test may not be as effective as it should be.
* Some hubs have errors in their descriptor, claiming
* to be self-powered when they are really bus-powered.
* We will overestimate the amount of current such hubs
* make available for each port.
*
* This is a fairly benign sort of failure. It won’t
* cause us to reject configurations that we should have
* accepted.
*/
/* Rule out configs that draw too much bus current */
//电源不足。配置描述符中的电力是所需电力的1/2
if （c->desc.bMaxPower * 2 > udev->bus_mA） {
insufficient_power++;
continue;
}
/* When the first config’s first interface is one of Microsoft’s
* pet nonstandard Ethernet-over-USB protocols, ignore it unless
* this kernel has enabled the necessary host side driver.
*/
if （i == 0 && desc && （is_rndis（desc） || is_activesync（desc））） {
#if !defined（CONFIG_USB_NET_RNDIS_HOST） && !defined（CONFIG_USB_NET_RNDIS_HOST_MODULE）
continue;
#else
best = c;
#endif
}
/* From the remaining configs, choose the first one whose
* first interface is for a non-vendor-specific class.
* Reason: Linux is more likely to have a class driver
* than a vendor-specific driver. */
//选择一个不是USB_CLASS_VENDOR_SPEC的配置
else if （udev->descriptor.bDeviceClass !=
USB_CLASS_VENDOR_SPEC &&
（！desc || desc->bInterfaceClass !=
USB_CLASS_VENDOR_SPEC）） {
best = c;
break;
}
/* If all the remaining configs are vendor-specific,
* choose the first one. */
else if （！best）
best = c;
}
if （insufficient_power > 0）
dev_info（&udev->dev, “rejected %d configuration%s “
“due to insufficient available bus power\n”,
insufficient_power, plural（insufficient_power））；
//如果选择好了配置，返回配置的序号，否则，返回-1
if （best） {
i = best->desc.bConfigurationValue;
dev_info（&udev->dev,
“configuration #%d chosen from %d choice%s\n”,
i, num_configs, plural（num_configs））；
} else {
i = -1;
dev_warn（&udev->dev,
“no configuration chosen from %d choice%s\n”,
num_configs, plural（num_configs））；
}
return i;
}
Linux按照自己的喜好选择好了配置之后，返回配置的序号。不过对于HUB来说，它有且仅有一个配置。
4.2.2:usb_set_configuration（）函数分析
既然已经选好配置了，那就告诉设备选好的配置，这个过程是在usb_set_configuration（）中完成的。它的代码如下：
int usb_set_configuration（struct usb_device *dev, int configuration）
{
int i, ret;
struct usb_host_config *cp = NULL;
struct usb_interface **new_interfaces = NULL;
int n, nintf;
if （dev->authorized == 0 || configuration == -1）
configuration = 0;
else {
for （i = 0; i < dev->descriptor.bNumConfigurations; i++） {
if （dev->config[i].desc.bConfigurationValue ==
configuration） {
cp = &dev->config[i];
break;
}
}
}
if （（！cp && configuration != 0））
return -EINVAL;
/* The USB spec says configuration 0 means unconfigured.
* But if a device includes a configuration numbered 0,
* we will accept it as a correctly configured state.
* Use -1 if you really want to unconfigure the device.
*/
if （cp && configuration == 0）
dev_warn（&dev->dev, “config 0 descriptor??\n”）；
首先，根据选择好的配置号找到相应的配置，在这里要注意了， dev->config[]数组中的配置并不是按照配置的序号来存放的，而是按照遍历到顺序来排序的。因为有些设备在发送配置描述符的时候，并不是按照配置序号来发送的，例如，配置2可能在第一次GET_CONFIGURATION就被发送了，而配置1可能是在第二次GET_CONFIGURATION才能发送。
取得配置描述信息之后，要对它进行有效性判断，注意一下本段代码的最后几行代码：usb2.0 spec上规定，0号配置是无效配置，但是可能有些厂商的设备并末按照这一约定，所以在linux中，遇到这种情况只是打印出警告信息，然后尝试使用这一配置。
/* Allocate memory for new interfaces before doing anything else,
* so that if we run out then nothing will have changed. */
n = nintf = 0;
if （cp） {
//接口总数
nintf = cp->desc.bNumInterfaces;
//interface指针数组，
new_interfaces = kmalloc（nintf * sizeof（*new_interfaces），
GFP_KERNEL）；
if （！new_interfaces） {
dev_err（&dev->dev, “Out of memory\n”）；
return -ENOMEM;
}
for （； n < nintf; ++n） {
new_interfaces[n] = kzalloc（
sizeof（struct usb_interface），
GFP_KERNEL）；
if （！new_interfaces[n]） {
dev_err（&dev->dev, “Out of memory\n”）；
ret = -ENOMEM;
free_interfaces:
while （–n >= 0）
kfree（new_interfaces[n]）；
kfree（new_interfaces）；
return ret;
}
}
//如果总电源小于所需电流，打印警告信息
i = dev->bus_mA – cp->desc.bMaxPower * 2;
if （i < 0）
dev_warn（&dev->dev, “new config #%d exceeds power “
“limit by %dmA\n”,
configuration, -i）；
}
在这里，注要是为new_interfaces分配空间，要这意的是， new_interfaces是一个二级指针，它的最终指向是struct usb_interface结构。特别的，如果总电流数要小于配置所需电流，则打印出警告消息。实际上，这种情况在usb_choose_configuration（）中已经进行了过滤。
/* Wake up the device so we can send it the Set-Config request */
//要对设备进行配置了，先唤醒它
ret = usb_autoresume_device（dev）；
if （ret）
goto free_interfaces;
/* if it’s already configured, clear out old state first.
* getting rid of old interfaces means unbinding their drivers.
*/
//不是处于ADDRESS状态，先清除设备的状态
if （dev->state != USB_STATE_ADDRESS）
usb_disable_device（dev, 1）； /* Skip ep0 */
//发送控制消息，选取配置
ret = usb_control_msg（dev, usb_sndctrlpipe（dev, 0），
USB_REQ_SET_CONFIGURATION, 0, configuration, 0,
NULL, 0, USB_CTRL_SET_TIMEOUT）；
if （ret < 0） {
/* All the old state is gone, so what else can we do?
* The device is probably useless now anyway.
*/
cp = NULL;
}
//dev->actconfig存放的是当前设备选取的配置
dev->actconfig = cp;
if （！cp） {
usb_set_device_state（dev, USB_STATE_ADDRESS）；
usb_autosuspend_device（dev）；
goto free_interfaces;
}
//将状态设为CONFIGURED
usb_set_device_state（dev, USB_STATE_CONFIGURED）；
接下来，就要对设备进行配置了，首先，将设备唤醒。回忆一下我们在分析UHCI驱动时，列出来的设备状态图。只有在ADDRESS状态才能转入到CONFIG状态。（SUSPEND状态除外）。 所以，如果设备当前不是处于ADDRESS状态，就需要将设备的状态初始化。usb_disable_device（）函数是个比较重要的操作，在接下来再对它进行详细分析。
接着，发送SET_CONFIGURATION的Control消息给设备，用来选择配置
最后，将dev->actconfig指向选定的配置，将设备状态设为CONFIG
/* Initialize the new interface structures and the
* hc/hcd/usbcore interface/endpoint state.
*/
//遍历所有的接口
for （i = 0; i < nintf; ++i） {
struct usb_interface_cache *intfc;
struct usb_interface *intf;
struct usb_host_interface *alt;
cp->interface[i] = intf = new_interfaces[i];
intfc = cp->intf_cache[i];
intf->altsetting = intfc->altsetting;
intf->num_altsetting = intfc->num_altsetting;
//是否关联的接口描述符，定义在minor usb 2.0 spec中
intf->intf_assoc = find_iad（dev, cp, i）；
kref_get（&intfc->ref）；
//选择0号设置
alt = usb_altnum_to_altsetting（intf, 0）；
/* No altsetting 0? We’ll assume the first altsetting.
* We could use a GetInterface call, but if a device is
* so non-compliant that it doesn’t have altsetting 0
* then I wouldn’t trust its reply anyway.
*/
//如果0号设置不存在，选排在第一个设置
if （！alt）
alt = &intf->altsetting[0];
//当前的配置
intf->cur_altsetting = alt;
usb_enable_interface（dev, intf）；
intf->dev.parent = &dev->dev;
intf->dev.driver = NULL;
intf->dev.bus = &usb_bus_type;
intf->dev.type = &usb_if_device_type;
intf->dev.dma_mask = dev->dev.dma_mask;
device_initialize（&intf->dev）；
mark_quiesced（intf）；
sprintf（&intf->dev.bus_id[0], “%d-%s:%d.%d”,
dev->bus->busnum, dev->devpath,
configuration, alt->desc.bInterfaceNumber）；
}
kfree（new_interfaces）；
if （cp->string == NULL）
cp->string = usb_cache_string（dev, cp->desc.iConfiguration）；
之前初始化的new_interfaces在这里终于要派上用场了。初始化各接口，从上面的初始化过程中，我们可以看出：
Intf->altsetting,表示接口的各种设置
Intf->num_altsetting:表示接口的设置数目
Intf->intf_assoc:接口的关联接口（定义于minor usb 2.0 spec）
Intf->cur_altsetting:接口的当前设置。
结合之前在UHCI中的分析，我们总结一下：
Usb_dev->config,其实是一个数组，存放设备的配置。usb_dev->config[m]-> interface[n]表示第m个配置的第n个接口的intercace结构。（m,n不是配置序号和接口序号 *^_^*）。
注意这个地方对intf内嵌的struct devcie结构赋值，它的type被赋值为了usb_if_device_type.bus还是usb_bus_type.可能你已经反应过来了，要和这个device匹配的设备是interface的驱动。
特别的，这里的device的命名：
sprintf（&intf->dev.bus_id[0], “%d-%s:%d.%d”,
dev->bus->busnum, dev->devpath,
configuration, alt->desc.bInterfaceNumber）；
dev指的是这个接口所属的usb_dev,结合我们之前在UHCI中关于usb设备命名方式的描述。可得出它的命令方式如下：
USB总线号-设备路径：配置号。接口号。
例如，在我的虚拟机上：
[root@localhost devices]# pwd
/sys/bus/usb/devices
[root@localhost devices]# ls
1-0:1.0 usb1
[root@localhost devices]#
可以得知，系统只有一个usb control.
1-0:1.0:表示，第一个usb control下的root hub的1号配置的0号接口。
[1][2][3][4]
只有经历过地狱般的折磨，才有征服天堂的力量。
