|
一：前言 继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号接口。
 【责编:cc】 |
|
|
