Inside_Linux_PCIBusDriver2
Linux设备驱动之USBhub驱动
Linux设备驱动之USB hub驱动Linux设备驱动之USB hub驱动------------------------------------------本文系本站原创,欢迎!请注明出处:------------------------------------------一:前言继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-> = (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-> = (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 dr iver %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){/* 整理by *///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;/*整理by */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){…………retval = usb_register_device_driver(&usb_generic_driver, THIS_MODULE);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,#ifdefCONFIG_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 deviceif (!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_t: autosuspend计数.如果此计数为1,则不允许autosuspendudev->pm_usage_t = !(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_t被设为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中显示几个属性文件,不进行详细分析,有兴趣的可以结合之前分析的>来看下代码.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; istruct 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 bee 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/2if (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;#elsebest = 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));//如果选择好了配置,返回配置的序号,否则,返回-1if (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 descriptor.bNumConfigurations; i++) {if (dev->config.desc.bConfigurationValue ==configuration) {cp = &dev->config;break;}}}if ((!cp && configuration != 0))return -EINV AL;/* 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 (; nnew_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 (idev_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/* 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_STA TE_ADDRESS);usb_autosuspend_device(dev);goto free_interfaces;}//将状态设为CONFIGUREDusb_set_device_state(dev, USB_STA TE_CONFIGURED);接下来,就要对设备进行配置了,首先,将设备唤醒.回忆一下我们在分析UHCI驱动时,列出来的设备状态图.只有在ADDRESS状态才能转入到CONFIG状态.(SUSPEND状态除外). 所以,如果设备当前不是处于ADDRESS状态,就需要将设备的状态初始化.usb_disable_device()函数是个比较重要的操作,在接下来再对它进行详细分析.接着,发送SET_CONFIGURA TION的Control消息给设备,用来选择配置最后,将dev->actconfig指向选定的配置,将设备状态设为CONFIG/* Initialize the new interface structures and the* hc/hcd/usbcore interface/endpoint state.*///遍历所有的接口for (i = 0; istruct usb_interface_cache *intfc;struct usb_interface *intf;struct usb_host_interface *alt;cp->interface = intf = new_interfaces;intfc = cp->intf_cache;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-pliant that it doesn’t have altsetting 0* then I would n’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,bsp; dev->bus->busnum, dev->devpath,configuration, alt->desc.bInterfaceNumber);dev指的是这个接口所属的usb_dev,结合我们之前在UHCI中关于usb设备命名方式的描述.可得出它的命令方式如下:USB总线号-设备路径:配置号.接口号.例如,在我的虚拟机上:[rootlocalhost devices]# pwd/sys/bus/usb/devices[rootlocalhost devices]# ls1-0:1.0usb1[rootlocalhost devices]#可以得知,系统只有一个usb control.1-0:1.0:表示,第一个usb cont意思上看来,它是标记接口为停止状态.它的”反函数”是mark_active().两个函数如下示:static inline void mark_active(struct usb_interface *f){f->is_active = 1;f->dev.power.power_state.event = PM_EVENT_ON;}static inline void mark_quiesced(struct usb_interface *f){f->is_active = 0;f->dev.power.power_state.event = PM_EVENT_SUSPEND; }从代码看来,它只是对接口的活动标志(is_active)进行了设置./* Now that all the interfaces are set up, register them* to trigger binding of drivers to interfaces.probe()* routines may install different altsettings and may* claim() any interfaces not yet bound.Many class drivers* need that: CDC, audio, video, etc.*///注册每一个接口?for (i = 0; istruct usb_interface *intf = cp->interface;dev_dbg(&dev->dev,“addi ng %s (config #%d, interface %d)\n”,intf->dev.bus_id, configuration,intf->cur_altsetting->desc.bInterfaceNumber);ret = device_add(&intf->dev);if (ret != 0) {dev_err(&dev->dev, “device_add(%s) --> %d\n”,intf->dev.bus_id, ret);continue;}usb_create_sysfs_intf_files(intf);}//使设备suspendusb_autosuspend_device(dev);return 0;}最后,注册intf内嵌的device结构.设备配置完成了,为了省电,可以将设备置为SUSPEND状态.这个函数中还有几个比较重要的子函数,依次分析如下:1: usb_disable_device()函数.顾名思义,这个函数是将设备disable掉.代码如下:void usb_disable_device(struct usb_device *dev, int skip_ep0){int i;dev_dbg(&dev->dev, “%s nuking %s URBs\n”, __FUNCTION__, skip_ep0 ? “non-ep0” : “all”);for (i = skip_ep0; iusb_disable_endpoint(dev, i);usb_disable_endpoint(dev, i + USB_DIR_IN);}dev->toggle[0] = dev->toggle[1] = 0;/* getting rid of interfaces will disconnect* any drivers bound to them (a key side effect)*/if (dev->actconfig) {for (i = 0; i actconfig->desc.bNumInterfaces; i++) {struct usb_interface *interface;/* remove this interface if it has been registered */interface = dev->actconfig->interface;if (!device_is_registered(&interface->dev))continue;dev_dbg(&dev->dev, “unregistering interface %s\n”,interface->dev.bus_id);usb_remove_sysfs_intf_files(interface);device_del(&interface->dev);}/* Now that the interfaces are unbound, nobody should* try to access them.*/for (i = 0; i actconfig->desc.bNumInterfaces; i++) {put_device(&dev->actconfig->interface->dev);dev->actconfig->interface = NULL;}dev->actconfig = NULL;if (dev->state == USB_STATE_CONFIGURED)usb_set_device_state(dev, USB_STATE_ADDRESS);}}第二个参数是skip_ep0.是表示是否跳过ep0.为1表示跳过,为0表示清除掉设备中的所有endpoint.这个函数可以分为两个部份,一部份是对usb_dev中的endpoint进行操作,一方面是释放usb_dev的选定配置项.对于第一部份:从代码中可能看到,如果skip_ep0为1,那就是从1开始循环,所以,就跳过了ep0.另外,一个端点号对应了两个端点,一个IN,一个OUT.IN端点比OUT端点要大USB_DIR_IN.另外,既然设备都已经被禁用了,那toggle也应该回归原位了.因些将两个方向的toggle都设为0. usb_disable_endpoint()是一个很有意思的处理.它的代码如下:void usb_disable_endpoint(struct usb_device *dev, unsigned int epaddr){unsigned int epnum = epaddr & USB_ENDPOINT_NUMBER_MASK;struct usb_host_endpoint *ep;if (!dev)return;//在dev->ep_out和dev->ep_in删除endpointif (usb_endpoint_out(epaddr)) {ep = dev->ep_out[epnum];dev->ep_out[epnum] = NULL;} else {ep = dev->ep_in[epnum];dev->ep_in[epnum] = NULL;}//禁用掉此ep.包括删除ep上提交的urb 和ep上的QHif (ep) {ep->enabled = 0;usb_hcd_flush_endpoint(dev, ep);usb_hcd_disable_endpoint(dev, ep);}}在dev->ep_in[]/dev->ep_out[]中删除endpoint,这点很好理解.比较难以理解的是后面的两个操作,即usb_hcd_flush_endpoint()和usb_hcd_disable_endpoint().根据之前分析的UHCI的驱动,我们得知,对于每个endpoint都有一个传输的qh,这个qh上又挂上了要传输的urb.因此,这两个函数一个是删除urb,一个是删除qh.usb_hcd_flush_endpoint()的代码如下:void usb_hcd_flush_endpoint(struct usb_device *udev,struct usb_host_endpoint *ep){struct usb_hcd *hcd;struct urb *urb;if (!ep)return;might_sleep();hcd = bus_to_hcd(udev->bus);/* No more submits can occur *///在提交urb时,将urb加到ep->urb_list上的时候要持锁//因此,这里持锁的话,无法发生中断和提交urbspin_lock_irq(&hcd_urb_list_lock);rescan://将挂在ep->urb_list上的所有urb unlink.注意这里unlink一般只会设置urb->unlinked的//值,不会将urb从ep->urb_list上删除.只有在UHCI的中断处理的时候,才会调用//uhci_giveback_urb()将其从ep->urb_list中删除list_for_each_entry (urb, &ep->urb_list, urb_list) {int is_in;if (urb->unlinked)continue;usb_get_urb (urb);is_in = usb_urb_dir_in(urb);spin_unlock(&hcd_urb_list_lock);/* kick hcd */unlink1(hcd, urb, -ESHUTDOWN);dev_dbg (hcd->self.controller,“shutdown urb %p ep%d%s%s\n”,urb, usb_endpoint_num(&ep->desc),is_in ? “in” : “out”,({char *s;switch (usb_endpoint_type(&ep->desc)) {case USB_ENDPOINT_XFER_CONTROL:s = ““; break;case USB_ENDPOINT_XFER_BULK:s = “-bulk”; break;case USB_ENDPOINT_XFER_INT:s = “-intr”; break;default:s = “-iso”; break;};s;}));usb_put_urb (urb);/* list contents may have changed *///在这里解开锁了,对应ep->urb_list上又可以提交urb. //这里释放释的话,主要是为了能够产生中断spin_lock(&hcd_urb_list_lock);goto rescan;}spin_unlock_irq(&hcd_urb_list_lock);/* Wait until the endpoint queue is pletely empty *///等待urb被调度完while (!list_empty (&ep->urb_list)) {spin_lock_irq(&hcd_urb_list_lock);/* The list may have changed while we acquired the spinlock */urb = NULL;if (!list_empty (&ep->urb_list)) {urb = list_entry (ep->urb_list.prev, struct urb,urb_list);usb_get_urb (urb);}spin_unlock_irq(&hcd_urb_list_lock);if (urb) {usb_kill_urb (urb);usb_put_urb (urb);}}}仔细体会这里的代码,为什么在前一个循环中,要使用goto rescan重新开始这个循环呢?这是因为在后面已经将自旋锁释放了,因此,就会有这样的可能,在函数中操作的urb,可能已经被调度完释放了.因此,再对这个urb操作就会产生错误.所以,需要重新开始这个循环.那后一个循环又是干什么的呢?后一个循环就是等待urb被调度完.有人就会有这样的疑问了,这里一边等待,然后endpoint一边还提交urb,那这个函数岂不是要耗掉很长时间?在这里,不要忘记了前面的操作,在调这个函数之前, usb_disable_endpoint()已经将这个endpoint禁用了,也就是说该endpoint不会产生新的urb.因为,在后一个循环中,只需要等待那些被unlink的urb调度完即可.在usb_kill_urb()中,会一直等待,直到这个urb被调度完成为止.可能有人又会有这样的疑问:Usb_kill_urb()中也有unlink urb的操作,为什么这里要分做两个循环呢?另外的一个函数是usb_hcd_disable_endpoint().代码如下:void usb_hcd_disable_endpoint(struct usb_device *udev,struct usb_host_endpoint *ep){struct usb_hcd *hcd;might_sleep();hcd = bus_to_hcd(udev->bus);if (hcd->driver->endpoint_disable)hcd->driver->endpoint_disable(hcd, ep);}从上面的代码可以看到,操作转向了hcd->driver的endpoint_disable()接口.以UHCI为例.在UHCI中,对应的接口为:static void uhci_hcd_endpoint_disable(struct usb_hcd *hcd,struct usb_host_endpoint *hep){struct uhci_hcd *uhci = hcd_to_uhci(hcd); struct uhci_qh *qh;spin_lock_irq(&uhci->lock);qh = (struct uhci_qh *) hep->hcpriv;if (qh == NULL)goto done;while (qh->state != QH_STA TE_IDLE) { ++uhci->num_waiting;spin_unlock_irq(&uhci->lock);wait_event_interruptible(uhci->waitqh, qh->state == QH_STATE_IDLE); spin_lock_irq(&uhci->lock);--uhci->num_waiting;}uhci_free_qh(uhci, qh);done:spin_unlock_irq(&uhci->lock);}这个函数没啥好说的,就是在uhci->waitqh上等待队列状态变为QH_STATE_IDLE.来回忆一下,qh在什么情况下才会变为QH_STATE_IDLE呢? 是在qh没有待传输的urb的时候.然后,将qh释放.现在我们来接着看usb_disable_device()的第二个部份.第二部份主要是针对dev->actconfig进行的操作, dev->actconfig存放的是设备当前的配置,现在要将设备设回Address状态.就些东西当然是用不了上的了.释放dev->actconfig->interface[]中的各元素,注意不要将dev->actconfig->interface[]所指向的信息释放了,它都是指向dev->config[]-> intf_cache[]中的东西,这些东西一释放,usb device在Get_ Configure所获得的信息就会部丢失了.就这样, usb_disable_device()函数也走到了尾声.2: usb_cache_string()函数这个函数我们在分析UHCI的时候已经接触过,但末做详细的分析.首先了解一下这个函数的作用,有时候,为了形象的说明,会提供一个字符串形式的说明.例如,对于配置描述符来说,它的iConfiguration就表示一个字符串索引,然后用Get_String就可以取得这个索引所对应的字串了.不过,事情并不是这么简单.因为字符串对应不同的编码,所以这里还会对应有编码的处理.来看具体的代码:char *usb_cache_string(struct usb_device *udev, int index){char *buf;char *smallbuf = NULL;int len;if (indexreturn NULL;//不知道字符到底有多长,就按最长256字节处理buf = kmalloc(256, GFP_KERNEL);if (buf) {len = usb_string(udev, index, buf, 256);//取到字符了,分配合适的长度if (len > 0) {smallbuf = kmalloc(++len, GFP_KERNEL);if (!smallbuf)return buf;//将字符copy过去memcpy(smallbuf, buf, len);}//释放旧空间kfree(buf);}return smallbuf;}这个函数没啥好说的,流程转入到usb_string中.代码如下:int usb_string(struct usb_device *dev, int index, char *buf, size_t size) {unsigned char *tbuf;int err;unsigned int u, idx;if (dev->state == USB_STATE_SUSPENDED)return -EHOSTUNREACH;if (sizereturn -EINV AL;buf[0] = 0;tbuf = kmalloc(256, GFP_KERNEL);if (!tbuf)return -ENOMEM;/* get langid for strings if it’s not yet known *///先取得设备支持的编码IDif (!dev->have_langid) {//以0号序号和编码0,Get_String就可得到设备所支持的编码列表err = usb_string_sub(dev, 0, 0, tbuf);//如果发生了错误,或者是取得的数据超短(最短为4字节)if (errdev_err(&dev->dev,“string descriptor 0 read error: %d\n”,err);goto errout;} else if (errdev_err(&dev->dev, “string desc riptor 0 too short\n”);err = -EINV AL;goto errout;}//取设备支持的第一个编码else {dev->have_langid = 1;dev->string_langid = tbuf[2] | (tbuf[3]/* always use the first langid listed */dev_dbg(&dev->dev, “default language 0x%04x\n”,dev->string_langid);}}//以编码ID和序号Index作为参数Get_String取得序号对应的字串err = usb_string_sub(dev, dev->string_langid, index, tbuf);if (errgoto errout;//空一个字符来用来存放结束符size--; /* leave room for trailing NULL char in output buffer */ //两字节一组,(Unicode编码的)for (idx = 0, u = 2; uif (idx >= size)break;//如果高字节有值,说明它不是ISO-8859-1编码的,将它置为? //否则,就将低位的值存放到buf中if (tbuf[u+1]) /* high byte */buf[idx++] = ‘?’;/* non ISO-8859-1 character */elsebuf[idx++] = tbuf;}//在最后一位赋0,字串结尾buf[idx] = 0;//返回字串的长度,(算上了最后的结尾字符)err = idx;//如果该描述符不是STRING描述符,打印出错误提示if (tbuf[1] != USB_DT_STRING)dev_dbg(&dev->dev,“wrong descriptor type %02x for string %d (\”%s\”)\n”,tbuf[1], index, buf);。
Linux系统中列出PCI设备和USB设备的命令详解
Linux系统中列出PCI设备和USB设备的命令详解lspciNAMElspci - 列出所有PCI设备 [[ ]]总览 SYNOPSISlspci [ options ] [[ ]]描述 DESCRIPTIONlspci 是⼀个⽤来显⽰系统中所有PCI总线设备或连接到该总线上的所有设备的⼯具。
为了能使⽤这个命令所有功能，你需要有 linux 2.1.82 或以上版本，⽀持 /proc/bus/pci 接⼝的内核。
在旧版本内核中，PCI⼯具必须使⽤只有root才能执⾏的直接硬件访问，⽽且总是出现竞争状况以及其他问题。
如果你要报告 PCI 设备驱动中，或者是 lspci ⾃⾝的 bugs，请在报告中包含 "lspci -vvx" 的输出。
[[ ]]选项 OPTIONS-v使得 lspci 以冗余模式显⽰所有设备的详细信息。
-vv使得 lspci 以过冗余模式显⽰更详细的信息 (事实上是 PCI 设备能给出的所有东西)。
这些数据的确切意义没有在此⼿册页中解释，如果你想知道更多，请参照 /usr/include/linux/pci.h 或者 PCI 规范。
-n以数字形式显⽰ PCI ⽣产⼚商和设备号，⽽不是在 PCI ID 数据库中查找它们。
-x以⼗六进制显⽰ PCI 配置空间 (configuration space) 的前64个字节映象 (标准头部信息)。
此参数对调试驱动和 lspci 本⾝很有⽤。
-xxx以⼗六进制显⽰所有 PCI 配置空间的映象。
此选项只有 root 可⽤，并且很多 PCI 设备在你试图读取配置空间的未定义部分时会崩溃 (此操作可能不违反PCI标准，但是它⾄少⾮常愚蠢)。
-b以总线为中⼼进⾏查看。
显⽰所有 IRQ 号和内存地址，就象 PCI 总线上的卡看到的⼀样，⽽不是内核看到的内容。
-t以树形⽅式显⽰包含所有总线、桥、设备和它们的连接的图表。
-s [[<bus>]:][<slot>][.[<func>]]仅显⽰指定总线、插槽上的设备或设备上的功能块信息。
支持V2显示芯片LVDS输出的Linux驱动
支持V2显示芯片LVDS输出的Linux驱动
随着技术的不断发展，LVDS（低电压差分信号）芯片的应用
已越来越广泛，尤其是在显示器驱动领域。
在Linux操作系统下，如何支持LVDS显示芯片的输出是一个重要的问题。
本
文将介绍如何编写支持V2显示芯片LVDS输出的Linux驱动。
首先，需要了解LVDS显示芯片的工作原理。
LVDS是一种高
速传输信号，通过将信号分为两个相反的信号进行传输，从而降低了信号传输过程中出现噪声的可能性，提高了数据传输的稳定性和可靠性。
支持LVDS输出的显示芯片也是如此，它
通过将图像数据分为两个信号进行传输，从而实现稳定和清晰的显示效果。
接下来，我们需要了解如何编写LVDS输出的Linux驱动。
首先，需要按照LVDS输出的协议规范，对驱动程序进行开发。
其中，需要定义LVDS输出的格式、像素时钟频率等。
根据LVDS输出信号的特性，编写对应的驱动程序，实现LVDS输
出数据的捕捉、处理和传输。
在编写完驱动程序后，需要进行系统的配置和调试。
首先，需要将驱动程序加载到Linux内核中，并配置相关参数，如显示
器分辨率、像素时钟频率等。
同时，还需要进行各种测试，如显示器的测试、图像质量的测试等，以保证LVDS输出的稳
定性和可靠性。
总结而言，支持V2显示芯片LVDS输出的Linux驱动需要按
照协议规范进行开发，实现数据的捕捉、处理和传输，并进行
系统的配置和调试工作。
这样才能满足现代高速传输信号的需求，提高显示效果的稳定性和可靠性，从而更好的满足用户的需求。
linux查看驱动版本
Linux下查看驱动版本以及硬件信息2009-05-13 09:58lsmod 看看你要查看的驱动模块名字，例如100M网卡e100modinfo e100 则会出现相关的版本信息常用命令整理如下：用硬件检测程序kuduz探测新硬件：service kudzu start ( or restart)查看CPU信息：cat /proc/cpuinfo查看板卡信息：cat /proc/pci查看PCI信息：lspci (相比cat /proc/pci更直观）查看内存信息：cat /proc/meminfo查看USB设备：cat /proc/bus/usb/devices查看键盘和鼠标:cat /proc/bus/input/devices查看系统硬盘信息和使用情况：fdisk & disk - l & df查看各设备的中断请求(IRQ):cat /proc/interrupts查看系统体系结构：uname -admidecode查看硬件信息，包括bios、cpu、内存等信息dmesg | more 查看硬件信息对于“/proc”中文件可使用文件查看命令浏览其内容，文件中包含系统特定信息：Cpuinfo 主机CPU信息Dma 主机DMA通道信息Filesystems 文件系统信息Interrupts 主机中断信息Ioprots 主机I/O端口号信息Meninfo 主机内存信息Version Linux内存版本信息另外我们还可以使用hardinfo 这个软件来查看硬件信息。
通常，linux系统启动的时候当加载网卡的时候，会产生一条日志信息写道/var/log/messages或者dmesg里面，这里面就有比较详细的网卡信息，包括版本号码等。
对于网卡：用ethtool -i ethX可以查询该网络设备的版本信息包括driver版本信息和firmware版本信息用此命令也能看到总线信息和该设备所用的driver模块名称假定该网卡使用的驱动模块是intel的e1000再用modinfo e1000就可看到该driver模块的详细信息查看网卡属性:ethtool -g eth0;查看网卡信息:dmesg。
linux 模拟硬件拔插的命令
linux 模拟硬件拔插的命令Linux模拟硬件拔插的命令在日常的Linux系统管理和维护中，经常会遇到需要模拟硬件拔插的情景。
这些情景可能是为了测试硬件设备的可靠性、检测驱动程序的兼容性，亦或是进行系统的故障排查。
本文将一步一步地回答关于Linux模拟硬件拔插的命令，并提供一些实例来帮助读者更好地理解。
1. Linux设备模拟工具简介在Linux系统中，可以使用一些设备模拟工具来模拟硬件的插拔操作。
这些工具可以模拟多种硬件设备，如USB设备、网卡、串口等，并提供与真实硬件设备一样的操作体验。
下面我们将介绍一些常用的设备模拟工具。
1.1 USB\_GADGETUSB\_GADGET是一个支持模拟USB设备的框架，可以用于在Linux设备上模拟USB设备插拔的操作。
它通过创建一个虚拟设备并将其绑定到相应的USB总线上来实现设备模拟。
使用USB\_GADGET需要在内核配置文件中启用相应的选项，并在系统启动时加载相应的内核模块。
一旦虚拟设备创建成功，可以通过向特定的配置文件写入命令来模拟设备的插拔。
1.2 EEMulatorEEMulator是一个开源的USB模拟器，支持模拟多种USB设备，如鼠标、键盘、摄像头等。
它可以通过虚拟机、容器、实体主机等多种方式运行，并提供与真实设备相同的输入输出接口。
EEMulator可以帮助开发人员测试其软件的USB设备兼容性，并提供了丰富的API和命令行工具以便进行设备模拟。
1.3 QEMUQEMU是一款开源的虚拟机监控器，可以模拟多种硬件平台的设备。
它支持通过命令行或图形界面进行设备模拟，并可模拟多种虚拟硬件设备，如网卡、声卡、USB等。
QEMU提供了灵活的配置选项，可以根据需要来进行设备模拟，并支持多种虚拟硬盘和光驱格式。
2. 使用USB\_GADGET模拟硬件插拔USB\_GADGET是一种内核模块，可用于模拟USB设备的插拔操作。
以下是一些使用USB\_GADGET模拟硬件插拔的实例。
Linux命令行中的硬件信息查看和驱动管理
Linux命令行中的硬件信息查看和驱动管理在Linux命令行中，我们可以通过一些命令来查看硬件信息和管理驱动，这对于系统维护和故障排除非常重要。
本文将介绍几个常用的命令及其用法，帮助您快速获取硬件信息和管理驱动。
1. 查看硬件信息1.1 lshw命令lshw（或者lswhw）是一个用于查看硬件信息的命令，可以列出系统中所有硬件的详细信息，包括处理器、内存、硬盘、网卡等。
使用示例：```$ sudo lshw```运行以上命令后，您将看到完整的硬件信息列表，可以通过滚动查看或者使用管道和grep命令过滤感兴趣的部分。
1.2 lspci命令lspci命令用于列出系统中所有PCI设备的信息，包括显卡、网卡、声卡等。
使用示例：```$ lspci```该命令会输出PCI设备的详细信息，可以通过管道和grep进行过滤。
1.3 lsusb命令lsusb命令用于列出系统中所有USB设备的信息。
使用示例：```$ lsusb```该命令会输出USB设备的详细信息，可以通过管道和grep进行过滤。
2. 管理驱动2.1 modprobe命令modprobe命令用于加载和卸载Linux内核模块，包括驱动程序。
使用示例：```$ sudo modprobe <module_name> // 加载模块$ sudo modprobe -r <module_name> // 卸载模块```其中，`<module_name>`为要加载或卸载的模块名称。
2.2 lsmod命令lsmod命令用于列出当前已加载的内核模块。
使用示例：```$ lsmod```该命令会输出已加载模块的列表，包括模块名称、使用次数等信息。
2.3 rmmod命令rmmod命令用于卸载已加载的内核模块。
使用示例：```$ sudo rmmod <module_name>```其中，`<module_name>`为要卸载的模块名称。
如何写linux pci设备驱动程序-看
何写linux pci设备驱动程序original file:/Documentation/pci.txt translated by terracePCI总线应用领域及其广泛并且令人惊奇。
不同的pci设备有不同的需求以及不同的问题。
因此，在linux内核中pci层支持就非常重要啦。
本文档就是想为驱动程序设计开发人员解决pci处理中的各种问题。
Pci设备驱动程序的结构现在有两种风格的的pci驱动程序结构：新风格的驱动（即让pci层来做大量设备探测工作并且支持热插拔功能）和旧风格的驱动（即由驱动程序自己探测设备）。
除非你有很好的理由，否则就不要用旧风格写驱动程序。
当驱动程序找到所驱动的设备后，将执行以下步骤：①.启用设备②.访问设备配置空间③.检测设备资源（如基地址和中断号）④.分配设备资源与设备通讯下文将论述以上大部分步骤，其余部分请参考,它有不错的注释。
如果没有配置pci 子系统（即CONFIG_PCI 没有置位），以下介绍的大部分函数都被定义为内联函数，它们要么是空的，要么返回对应的错误代码以避免在驱动中出现过多的条件宏ifdefs。
1.新风格的驱动程序新风格的驱动程序只是在初始化时调用pci_register_driver，调用时使用一个指向struct pci_driver 的结构指针。
该指针包含以下几个分量：name 驱动程序名称id_table 指向一个与驱动程序相关的设备ID表的指针。
大多数驱动程序应当用MODULE_DEVICE_TABLE(pci,…)将该设备ID表导出。
在调用prob( )时设成NULL 以让系统检测到所有的pci设备。
probe 指向设备检测函数prob( ) 的指针。
该函数将在pci设备ID与设备ID表匹配且还没有被其它驱动程序处理时（一般在对已存在的设备执行pci_register_driver或以后又有新设备插入时）被调用。
调用时传入一个指向struct pci_driver结构的指针和与设备匹配的设备ID表做参数。
文档：、linux-308内核I2C触摸屏移植
Linux3.0.8平台搭建移植文档——I2C触摸屏移植1.I2C子系统goodix电容屏采用I2C接口与处理器连接，我们要首先确保linux内核拥有对I2C子系统的支持，下面我们从子系统的配置和电容屏驱动两个方面进行移植修改1）配置I2C子系统支持#make menuconfigDevice Drivers ---><*> I2C support --->[*] Enable compatibility bits for old user-space (NEW)<*> I2C device interface< > I2C bus multiplexing support (NEW)[*] Autoselect pertinent helper modules (NEW)I2C Hardware Bus support --->进入I2C Hardware Bus support选项，选中以下内容：*** I2C system bus drivers (mostly embedded / system-on-chip) ***< > Synopsys DesignWare (NEW)<*> GPIO-based bitbanging I2C< > OpenCores I2C Controller (NEW)< > PCA9564/PCA9665 as platform device (NEW)<*> S3C2410 I2C Driver< > Simtec Generic I2C interface (NEW)...2.GOODIX电容屏移植1）添加goodix电容屏驱动将“goodix_touch.c”文件copy到drivers/input/touchscreen/目录下，并将"goodix_touch.h"、"goodix_queue.h"文件copy到include/linux/目录下，并修改Kconfig文件及Makefile文件支持触摸屏驱动的配置和编译#vi driver/input/touchscreen/Kconfig在config TOUCHSCREEN_TPS6507X选项的后面添加以下内容：config TOUCHSCREEN_GOODIXtristate "GOODIX based touchscreen"depends on I2ChelpIt is a android driver to support Gooidx's touchscreen whose nameis guitar on s5pv210 platform. The touchscreen can support multi-touch not more than two fingers.Say Y here to enable the driver for the touchscreen on theS5V SMDK board.If unsure, say N.To compile this driver as a module, choose M here:the module will be called goodix_touch.ko.#vi driver/input/touchscreen/Makefile在文件最后添加如下内容：obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix_touch.o2）添加i2c_board_info资源(电容屏)#vi arch/arm/mach-s5pv210/mach-smdkv210.c在smdkv210_i2c_devs0结构体数组定义中添加以下内容：...{ I2C_BOARD_INFO("24c08", 0x50), }, /* Samsung S524AD0XD1 */ { I2C_BOARD_INFO("wm8580", 0x1b), },{I2C_BOARD_INFO("Goodix-TS", 0x55),.irq = IRQ_EINT(4),},...3）配置电容屏选项#make menuconfigDevice Drivers --->Input device support --->...[*] Touchscreens ---><*> GOODIX based touchscreen4)make将在arch/arm/boot/下生成编译好的可执行程序zImage下载到开发板即可，执行命令“cat /dev/input/event0”，然后用手触摸屏幕会在终端看到输出打印的乱码信息，表示移植成功，如果没有打印信息或没有“/dev/input/event0”这个设备说明移植失败。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
§3 PCI 配置空间PCI 规范定义了三种类型的PCI 配置空间头部。
其中type 0用于标准的PCI 设备，type 1用于PCI 桥，type 2用于PCI CardBus 桥。
关于这三种类型的配置空间头部的具体信息可以参见PCI 规范文档。
不管是哪一种类型的配置空间头部，其前16个字节的格式都是相同的。
如下图6所示：因此，Linux 在include/linux/pci.h 头文件中一开始就定义了这相同格式的前16个字节。
如下：（1）厂商ID 和设备ID 寄存器的定义如下：#define PCI_VENDOR_ID 0x00 /* 16 bits */#define PCI_DEVICE_ID 0x02 /* 16 bits */（2）命令寄存器的定义如下：#define PCI_COMMAND 0x04 /* 16 bits */#define PCI_COMMAND_IO 0x1 /* Enable response in I/O space */#define PCI_COMMAND_MEMORY 0x2 /* Enable response in Memory space */ #define PCI_COMMAND_MASTER0x4 /* Enable bus mastering */#define PCI_COMMAND_SPECIAL0x8 /* Enable response to special cycles */#define PCI_COMMAND_INVALIDATE 0x10 /* Use memory write and invalidate */ #define PCI_COMMAND_VGA_PALETTE 0x20 /* Enable palette snooping */#define PCI_COMMAND_PARITY 0x40 /* Enable parity checking */#define PCI_COMMAND_WAIT 0x80 /* Enable address/data stepping */#define PCI_COMMAND_SERR 0x100 /* Enable SERR */#define PCI_COMMAND_FAST_BACK 0x200 /* Enable back-to-back writes */在上述宏定义中，宏PCI_COMMAND 表示命令寄存器在PCI 配置空间头部的位置，而其余10个PCI_COMMAND_XXX 宏定义则表示命令寄存器中各位的掩码。
PCI 规范当前只使用了命令寄存器中的低10位，具体含义可以参阅PCI 总线规范。
（3）状态寄存器的定义如下：#define PCI_STATUS 0x06 /* 16 bits */#define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */00h 04h 08h 0ch 3ch图6 PCI 配置空间头部的前16个字节#define PCI_STATUS_66MHZ 0x20 /* Support 66 Mhz PCI 2.1 bus */#define PCI_STATUS_UDF 0x40 /* Support User Definable Features [obsolete] */#define PCI_STATUS_FAST_BACK 0x80 /* Accept fast-back to back */#define PCI_STATUS_PARITY 0x100 /* Detected parity error */#define PCI_STATUS_DEVSEL_MASK 0x600 /* DEVSEL timing */#define PCI_STATUS_DEVSEL_FAST 0x000#define PCI_STATUS_DEVSEL_MEDIUM 0x200#define PCI_STATUS_DEVSEL_SLOW 0x400#define PCI_STATUS_SIG_TARGET_ABORT 0x800 /* Set on target abort */#define PCI_STATUS_REC_TARGET_ABORT 0x1000 /* Master ack of " */#define PCI_STATUS_REC_MASTER_ABORT 0x2000 /* Set on master abort */#define PCI_STATUS_SIG_SYSTEM_ERROR 0x4000 /* Set when we drive SERR */#define PCI_STATUS_DETECTED_PARITY 0x8000 /* Set on parity error */在上述宏定义中，宏PCI_STATUS表示状态寄存器在配置空间头部的位置。
而其余PCI_STATUS_XXX宏则表示状态寄存器中各位的含义。
注意！PCI规范当前只使用状态寄存器中的高12位，而低4位被保留。
（4）类代码和修订版本寄存器的定义如下：#define PCI_CLASS_REVISION 0x08 /* High 24 bits are class, low 8 revision */#define PCI_REVISION_ID 0x08 /* Revision ID */#define PCI_CLASS_PROG 0x09 /* Reg. Level Programming Interface */#define PCI_CLASS_DEVICE 0x0a /* Device class */其中，宏PCI_CLASS_REVISION用来指示类代码寄存器和修订版本寄存器一起所占用的双字在PCI配置空间中的位置，因此如果要一次性地读写这个双字的内容，就可以用该宏来作为配置空间中的地址索引。
而宏PCI_REVISION_ID则作为配置空间中RevisionID这个字节的配置空间地址索引，而宏PCI_CLASS_PROG则是配置空间中ClassCode中的配置接口字节的地址索引，宏PCI_CLASS_DEVICE表示类与子类这个word在配置空间中的字地址索引。
关于类代码和修订版本寄存器的具体格式请参阅PCI 规范文档。
（5）宏PCI_CACHE_LINE_SIZE表示配置空间头部中的Cache Line Size寄存器在配置空间中的字节地址索引。
（6）宏PCI_LATENCY_TIMER表示配置空间头部中的Latency Timer寄存器在配置空间中的字节地址索引。
（7）宏PCI_HEADER_TYPE表示配置空间头部中的HeaderType寄存器在配置空间中的字节地址索引。
HeaderType字节中的低7位表示配置空间头部的类型，值00h表示是标准PCI设备的配置空间头部，值01h表示PCI-to-PCI桥的配置空间头部，值02h表示CardBus桥的配置空间头部。
（8）宏PCI_BIST表示配置空间头部中的BIST寄存器（Built－In Self-Test）在配置空间中的字节地址索引。
BIST寄存器中的bit［3：0］表示完成代码，bit［7］表示设备是否支持BIST，bit［6］用来启动BIST。
通常设备自检因该在2秒内完成。
上述几个宏的完整定义如下：#define PCI_CACHE_LINE_SIZE 0x0c /* 8 bits */#define PCI_LATENCY_TIMER 0x0d /* 8 bits */#define PCI_HEADER_TYPE 0x0e /* 8 bits */#define PCI_HEADER_TYPE_NORMAL0#define PCI_HEADER_TYPE_BRIDGE 1#define PCI_HEADER_TYPE_CARDBUS 2#define PCI_BIST 0x0f /* 8 bits */#define PCI_BIST_CODE_MASK 0x0f /* Return result */#define PCI_BIST_START 0x40 /* 1 to start BIST, 2 secs or less */#define PCI_BIST_CAPABLE 0x80 /* 1 if BIST capable */§3.1 基地址寄存器（BAR）宏PCI_BASE_ADDRESS_0到PCI_BASE_ADDRESS_5分别表示配置空间头部中的基地址寄存器0～基地址寄存器5在配置空间中的双字地址索引。
其中，PCI_BASE_ADDRESS_2～5仅对标准PCI设备的0类型配置空间头部才有意义，而PCI_BASE_ADDRESS_0~1则适用于0类型和1类型配置空间头部。
BAR 中的bit［0］的值决定了这个BAR所指定的地址范围是在I/O映射空间内进行译码，还是在Memory映射空间内进行译码。
因此，宏PCI_BASE_ADDRESS_SPACE表示BAR中bit［0］位的位掩码，而宏PCI_BASE_ADDRESS_SPACE_IO和PCI_BASE_ADDRESS_SPACE_MEMORY就分别表示bit［0］位的两种可能值，也就分别对应于I/O映射空间和内存映射空间。
当BAR所指定的地址范围位于内存映射空间中时，BAR中的bit［2：1］这两位表示内存地址的类型。
因此宏PCI_BASE_ADDRESS_MEM_TYPE_MASK就表示bit［2：1］这两位的位掩码值。
而PCI_BASE_ADDRESS_MEM_TYPE_32/1M/64这三个宏则表示三种可能的内存地址类型。
BAR中的bit［3］表示内存范围是否为可预取（Prefetchable）的内存，宏PCI_BASE_ADDRESS_MEM_PREFETCH对应于这一位。
最后，宏PCI_BASE_ADDRESS_MEM_MASK（～0x0fUL＝0xfffffff0）表示内存映射方式下的BAR 中有效内存地址位掩码，显然PCI总线中最小的内存范围是256字节。
宏PCI_BASE_ADDRESS_IO_MASK （～0x03UL=0xfffffff8）表示I/O映射方式下的BAR中有效的I/O地址位掩码。
显然PCI总线中最小的I/O 地址范围是8个字节。
所有上述这些宏的定义如下：/** Base addresses specify locations in memory or I/O space.* Decoded size can be determined by writing a value of* 0xffffffff to the register, and reading it back. Only* 1 bits are decoded.*/#define PCI_BASE_ADDRESS_00x10 /* 32 bits */#define PCI_BASE_ADDRESS_10x14 /* 32 bits [htype 0,1 only] */#define PCI_BASE_ADDRESS_20x18 /* 32 bits [htype 0 only] */#define PCI_BASE_ADDRESS_30x1c /* 32 bits */#define PCI_BASE_ADDRESS_40x20 /* 32 bits */#define PCI_BASE_ADDRESS_50x24 /* 32 bits */#define PCI_BASE_ADDRESS_SPACE 0x01 /* 0 = memory, 1 = I/O */#define PCI_BASE_ADDRESS_SPACE_IO 0x01#define PCI_BASE_ADDRESS_SPACE_MEMORY 0x00#define PCI_BASE_ADDRESS_MEM_TYPE_MASK 0x06#define PCI_BASE_ADDRESS_MEM_TYPE_32 0x00 /* 32 bit address */#define PCI_BASE_ADDRESS_MEM_TYPE_1M 0x02 /* Below 1M [obsolete] */#define PCI_BASE_ADDRESS_MEM_TYPE_64 0x04 /* 64 bit address */#define PCI_BASE_ADDRESS_MEM_PREFETCH 0x08 /* prefetchable? */#define PCI_BASE_ADDRESS_MEM_MASK(~0x0fUL)#define PCI_BASE_ADDRESS_IO_MASK (~0x03UL)/* bit 1 is reserved if address_space = 1 */§3.2 类型0配置空间头部标准PCI设备的0类型配置空间头部的其余寄存器定义如下：/* Header type 0 (normal devices) */#define PCI_CARDBUS_CIS 0x28#define PCI_SUBSYSTEM_VENDOR_ID 0x2c#define PCI_SUBSYSTEM_ID 0x2e#define PCI_ROM_ADDRESS 0x30 /* Bits 31..11 are address, 10..1 reserved */#define PCI_ROM_ADDRESS_ENABLE 0x01#define PCI_ROM_ADDRESS_MASK (~0x7ffUL)#define PCI_CAPABILITY_LIST 0x34 /* Offset of first capability list entry *//* 0x35-0x3b are reserved */#define PCI_INTERRUPT_LINE 0x3c /* 8 bits */#define PCI_INTERRUPT_PIN 0x3d /* 8 bits */#define PCI_MIN_GNT 0x3e /* 8 bits */#define PCI_MAX_LAT 0x3f /* 8 bits */这里对ROM地址寄存器的定义说明一下。