Linux设备驱动程序学习(18)-USB 驱动程序(三)

一、引言USB(Universal Serial Bus)即通用串行总线，是一种全新的双向同步传输的支持热插拔的数据传输总线，其目的是为了提供一种兼容不同速度的、可扩充的并且使用方便的外围设备接口，同时也是为了解决计算机接口的太多的弊端而设计的。

一个USB系统主要有三部分组成：USB互连、USB主机、USB设备三部分组成的，其结构如图1所示。

在编写USB设备驱动程序设计时，可以分为三部分编写：主机端设备驱动程序、主机控制器驱动程序设计和设备端驱动程序三部分，在本文中重点介绍主机端驱动程序的设计。

二、USB设备驱动程序的设计USB设备驱动程序的设计包括主机端设备驱动程序设计、主机控制器驱动程序设计和设备端驱动程序设计三部分组成。

主机端设备驱动程序就是通常说的设备驱动程序，它是主机环境中为用户应用程序提供一个访问USB外设的接口。

Linux为这部分驱动程序提供编程接口，驱动程序设计者只要按照需求编写驱动程序框架，通过调用操作系统提供的API接口函数可以完成对USB外设的特定访问。

主机控制驱动主要是对USB主机控制器的驱动，在大多数PC环境下，主机控制器都是由操作系统提供。

嵌入式设备一般都没有USB主机控制器，只是工作在Slave模式下。

如果要使USB具有主机功能，那么设备中需要选用一个带主机控制器的USB接口控制芯片，同时自己还要有实现该主机控制器的驱动程序。

目前Linux内核中只提供USB主机控制器的开放主机控制器和通用主机控制器接口两种规格，而这两种规格主要用在PC架构中。

USB主机端驱动程序与主机控制器的结构如图2所示。

其中USB核是Linux的一个子模块，集中定义了一组USB相关的数据结构、宏以及API函数。

USB设备驱动程序是常说的设备固件程序的一部分，提供设备信息与主机的通信接口。

设备端USB驱动程序设计由以下几部分处理程序组成。

初始化例程：完成描述符指针、端点、配置改变等操作。

数据传输例程：完成控制传输、批量传输、中断传输及同步传输等传输方式下的数据收发工作。

linux安装usb驱动命令有时我们会用到usb设备，这时我们就要学会如何在linux系统下安装usb驱动了。

下面由店铺为大家整理了linux安装usb驱动命令的相关知识，希望大家喜欢!linux安装usb驱动命令安装方法及步骤：一、准备工作2、到/projects/ndiswrapper下载最新的ndiswrapper包，我的版本是ndiswrapper-1.52.tar.gz3、准备好网卡在Winxp下的驱动程序。

驱动程序最好是最新的，指定给XP用的。

二、安装及配置1、安装(1)解压：tar -zxvf ndiswrapper-1.52.tar.gz(2)进入ndiswrapper-1.52：cd ndiswrapper-1.52(3)编译：make//在此操作之前必需先把编译环境搭建好，即：安装好开发环境。

(4)安装：make install //如果不采取默认的安装路径，则可以用。

configure ——prefix="/etc/local"来指定安装目录。

//此目录是自建。

(5)查看安装后的版本ndiswrapper -v | grep //此处似乎不对。

如安装成功则显示version：1.51(6)获取该无线网卡的WindowsXP驱动，(7)进入该驱动所在目录：cd /home/tsm/dwl_g520(8)安装无线网卡驱动：ndiswrapper -i net5211.inf(9)查看驱动是否安装：ndiswrapper -l//如：显示net5211(驱动名称)：driver installed(10)写入配置文件：ndiswrapper -m ndiswrapper -ma ndiswrapper -mi(11)启动后模块自动加载：modprobe ndiswrapper补充：linux安装usb驱动命令出现的小问题及解决方法我是用ndiswrapper安装windows下的inf驱动的sony本本384M内存，4M集成显存，usb1.0接口，跑windows 速度比较慢，就像装个轻量级的操作系统。

嵌入式Linux下的USB设备驱动技术Linux以其稳定、高效、易定制、硬件支持广泛、源代码开放等特点，已在嵌入式领域迅速崛起，被国际上许多大型的跨国企业用作嵌入式产品的系统平台。

USB是Universal Serial Bus (通用串行总线)的缩写，是1995年由Microsoft、Compaq、IBM等公司联合制定的一种新的PC串行通信协议。

它是一种快速、灵活的总线接口。

与其它通信接口相比较，USB接口的最大特点是易于使用，这也是USB的主要设计目标。

USB的成功得益于在USB标准中除定义了通信的物理层和电器层标准外。

还定义了一套相对完整的软件协议堆栈。

这使得多数USB设备都很容易在各种平台上工作。

作为一种高速总线接口，USB适用于多种设备(如数码相机、MP3播放器、高速数据采集设备等)。

另外，USB接口还支持热插拔，而且所有的配置过程都由系统自动完成，无须用户干预。

1 Linux下的USB设备驱动在Linux内核的不断升级过程中，驱动程序的结构相对稳定。

由于USB设备也是外围设备的一种，因此，它的驱动程序结构与普通设备的驱动程序相同。

Linux系统的设备分为字符设备(CharDevice)和块设备(BlockDevice)。

字符设备支持面向块字符的I／O操作，它不通过系统的快速缓存，而只支持顺序存取。

块设备则支持面向块的I／O操作，所有块设备的I／O操作都通过在内核地址空间的I／O缓冲区进行，可以支持几乎任意长度和任意位置上的I／O请求。

块设备与字符设备还有一点不同，就是块设备必须能够随机存取(RandomAccess)，字符设备则没有这个要求。

典型的字符设备包括鼠标、键盘、串行口等，而块设备主要包括硬盘软盘设备、CD-Rom等。

由于USB设备主要都是通过快速串行通讯来读写数据，因此一般都可作为字符设备来进行处理。

2 Linux下的USB core2.1 Linux中USB core与USB的结构关系Linux操作系统中有一个叫做“USB core”的子系统，可提供支持USB设备驱动程序的API和USB主机控制器的驱动程序。

Linux下的硬件驱动——USB设备什么是USB设备？USB即Universal Serial Bus，翻译过来就是通用串行总线。

它是一种规范化的、快速的、热插拔的串行输入/输出接口。

USB接口常被用于连接鼠标、键盘、打印机、扫描仪、音频设备、存储设备等外围设备。

Linux下的USB驱动在Linux系统中，每个USB设备都需要一个相应的驱动程序来驱动。

从Linux 2.4开始，内核提供了完整的USB设备支持。

对于每个USB设备，内核都会自动加载对应的驱动程序。

Linux下的USB设备驱动程序主要分为以下几个部分：USB核心驱动程序USB核心驱动程序是操作系统内核中处理USB设备的核心模块，负责与各种类型的USB设备进行通信，包括主机控制器、USB总线、USB设备等。

它与驱动程序和应用程序之间起到了桥梁的作用，为驱动程序提供了USB设备的基础支持。

USB设备驱动程序USB设备驱动程序是与特定USB设备相对应的驱动程序，为USB设备提供具体的读写功能和其他控制功能。

USB核心驱动程序和USB设备驱动程序之间的接口USB核心驱动程序和USB设备驱动程序之间的接口是指USB层和应用程序层之间的接口，负责传递各种USB操作的命令和数据。

如何编译一个USB设备驱动编译一个USB设备驱动程序需要按照以下步骤进行：步骤一：安装必要的软件包首先需要安装编译和调试USB设备驱动所需的软件包，包括编译工具链、内核源代码、内核头文件等。

sudo apt-get install build-essential linux-source linux-headers-`una me -r`步骤二：编写代码现在可以编写USB设备驱动程序的代码，此处不做详细介绍。

步骤三：编译代码在终端窗口中进入USB设备驱动程序所在的目录下，输入以下命令进行编译：make此命令将会编译USB设备驱动程序，并生成一个将驱动程序与内核进行连接的模块文件。

25.2 USB驱动程序框架Linux内核提供了完整的USB驱动程序框架。

USB总线采用树形结构，在一条总线上只能有唯一的主机设备。

Linux内核从主机和设备两个角度观察USB总线结构。

本节介绍Linux内核USB驱动程序框架。

25.2.1 Linux内核USB驱动框架图25-2是Linux内核从主机和设备两个角度观察USB总线结构的示意图。

从图25-2中可以看出，Linux内核USB驱动是按照主机驱动和设备驱动两套体系实现的，下面介绍两套体系的结构和特点。

1．基本结构图25-2的左侧是主机驱动结构。

主机驱动的最底层是USB主机控制器，提供了OHCI/EHCI/UHCI这3种类型的总线控制功能。

在USB控制器的上一层是主机控制器的驱动，分别对应OHCI/EHCI/UHCI这3种类型的总线接口。

USB核心部分连接了USB控制器驱动和设备驱动，是两者之间的转换接口。

USB设备驱动层提供了各种设备的驱动程序。

USB主机部分的设计结构完全是从USB总线特点出发的。

在USB总线上可以连接各种不同类型的设备，包括字符设备、块设备和网络设备。

所有类型的USB设备都是用相同的电气接口，使用的传输协议也基本相同。

向用户提供某种特定类型的USB设备时，需要处理USB总线协议。

内核完成所有的USB总线协议处理，并且向用户提供编程接口。

图25-2 Linux内核USB总线结构图25-2右侧是设备驱动结构。

与USB主机类似，USB设备提供了相同的层次结构与之对应。

但是在USB设备一侧使用名为Gadget API的结构作为核心。

Gadget API是Linux内核实现的对应USB设备的核心结构。

Gadget API屏蔽了USB设备控制器的细节，控制具体的USB设备实现。

2．设备每个USB设备提供了不同级别的配置信息。

一个USB设备可以包含一个或多个配置，不同的配置使设备表现出不同的特点。

其中，设备的配置是通过接口组成的。

Linux内核定义了USB设备描述结构如下：struct usb_device_descriptor {__u8 bLength; // 设备描述符长度__u8 bDescriptorType; // 设备类型__le16 bcdUSB; // USB版本号（使用BCD编码）__u8 bDeviceClass; // USB设备类型__u8 bDeviceSubClass; // USB设备子类型__u8 bDeviceProtocol; // USB设备协议号__u8 bMaxPacketSize0; // 传输数据的最大包长__le16 idVendor; // 厂商编号__le16 idProduct; // 产品编号__le16 bcdDevice; // 设备出厂号__u8 iManufacturer; // 厂商字符串索引__u8 iProduct; // 产品字符串索引__u8 iSerialNumber; // 产品序列号索引__u8 bNumConfigurations; // 最大的配置数量} __attribute__ ((packed));从usb_device_descriptor结构定义看出，一个设备描述符定义了与USB设备有关的所有信息。

Linux下的USB总线驱动一．USB理论1. USB概念概述USB1.0版本速度1.5Mbps（低速USB）USB1.1版本速度12Mbps（全速USB）USB2.0版本速度480Mbps（高速USB）USB驱动由USB主机控制器驱动和USB设备驱动组成。

USB主机控制器是用来控制USB 设备和CPU之间通信的，USB主机控制器驱动主要用来驱动芯片上的主机控制器硬件。

US B设备驱动主要是指具体的例如USB鼠标，USB键盘灯设备的驱动。

一般的通用的Linux设备，如U盘、USB鼠标、USB键盘，都不需要工程师再编写驱动，需要编写的是特定厂商、特定芯片的驱动，而且往往也可以参考内核中已经提供的驱动模板。

USB只是一个总线，真正的USB设备驱动的主体工作仍然是USB设备本身所属类型的驱动，如字符设备、tty设备、块设备、输入设备等。

2. USB主机控制器USB主机控制器属于南桥芯片的一部分，通过PCI总线和处理器通信。

USB主机控制器分为UHCI（英特尔提出）、OHCI（康柏和微软提出）、EHCI。

其中OHCI驱动程序用来为非PC系统上以及带有SiS和ALi芯片组的PC主办上的USB芯片提供支持。

UHCI驱动程序多用来为大多数其他PC主板（包括Intel和Via）上的USB芯片提供支持。

ENCI兼容OHC I和UHCI。

UHCI的硬件线路比OHCI简单，所以成本较低，但需要较复杂的驱动程序，CP U负荷稍重。

主机控制器驱动程序完成的功能主要包括：解析和维护URB，根据不同的端点进行分类缓存URB；负责不同USB传输类型的调度工作；负责USB数据的实际传输工作；实现虚拟跟HUB的功能。

3. USB设备与USB驱动的匹配USB设备与USB驱动怎么匹配的呢？实际上USB设备中有一个模块叫固件，是固件信息和USB驱动进行的匹配。

固件是固化在集成电路内部的程序代码，USB固件中包含了USB设备的出厂信息，标识该设备的厂商ID、产品ID、主版本号和次版本号等。

详细介绍Linux USB驱动工作流程1. USB主机在Linux驱动中，USB驱动处于最底层的是USB主机控制器硬件，在其之上运行的是USB 主机控制器驱动，主机控制器之上为USB核心层，再上层为USB设备驱动层（插入主机上的U盘、鼠标、USB转串口等设备驱动）。

因此，在主机侧的层次结构中，要实现的USB驱动包括两类：USB主机控制器驱动和USB 设备驱动，前者控制插入其中的USB设备，后者控制USB设备如何与主机通信。

Linux 内核USB核心负责USB驱动管理和协议处理的主要工作。

主机控制器驱动和设备驱动之间的USB核心非常重要，其功能包括：通过定义一些数据结构、宏和功能函数，向上为设备驱动提供编程接口，向下为USB主机控制器驱动提供编程接口；通过全局变量维护整个系统的USB设备信息；完成设备热插拔控制、总线数据传输控制等。

2. USB设备Linux内核中USB设备侧驱动程序分为3个层次：UDC驱动程序、Gadget API和Gadget 驱动程序。

UDC驱动程序直接访问硬件，控制USB设备和主机间的底层通信，向上层提供与硬件相关操作的回调函数。

当前Gadget API是UDC驱动程序回调函数的简单包装。

Gadget驱动程序具体控制USB设备功能的实现，使设备表现出“网络连接”、“打印机”或“USB Mass Storage”等特性，它使用Gadget API控制UDC实现上述功能。

Gadget API 把下层的UDC驱动程序和上层的Gadget驱动程序隔离开，使得在Linux系统中编写USB 设备侧驱动程序时能够把功能的实现和底层通信分离。

3. 在USB设备组织结构中，从上到下分为设备（device）、配置（config）、接口（interface）和端点（endpoint）四个层次。

USB设备程序绑定到接口上。

对于这四个层次的简单描述如下：设备通常具有一个或多个的配置配置经常具有一个或多个的接口接口没有或具有一个以上的端点。

linux usb设备驱动和通信原理Linux USB设备驱动和通信原理一、介绍USB（Universal Serial Bus，通用串行总线）是一种常见的外部设备连接标准，可以连接各种设备，如打印机、键盘、鼠标、摄像头等。

在Linux系统中，USB设备驱动是用于管理和控制USB设备的软件模块。

本文将介绍Linux USB设备驱动的基本原理和USB设备与主机之间的通信过程。

二、USB设备驱动1. 驱动模型在Linux系统中，USB设备驱动使用一种称为USB核心（USB Core）的模型来管理和控制USB设备。

USB核心提供了一组功能强大的API，供驱动程序使用。

驱动程序通过注册到USB核心，并提供一组回调函数来处理USB设备的各种事件和请求。

2. 驱动加载当插入一个USB设备时，Linux内核会自动加载与之对应的驱动程序。

内核根据设备的厂商ID（Vendor ID）和产品ID（Product ID）来匹配设备和驱动程序。

如果找到匹配的驱动程序，内核会加载该驱动程序，并调用其初始化函数。

3. 驱动程序结构一个USB设备驱动程序通常由以下几个部分组成：- 初始化函数：用于初始化驱动程序的数据结构和资源。

- 描述符匹配函数：用于匹配设备的描述符和驱动程序。

- 事件处理函数：用于处理设备的插入、拔出等事件。

- 控制请求处理函数：用于处理来自主机的控制请求。

- 数据传输函数：用于处理设备和主机之间的数据传输。

三、USB设备与主机通信原理1. 设备描述符USB设备在与主机通信之前，需要提供一个设备描述符，用于描述设备的基本信息，如设备类别、厂商ID、产品ID等。

主机通过设备描述符来识别和配置设备。

2. 端点和传输类型USB设备与主机之间的通信是通过端点（Endpoint）来实现的。

一个USB设备通常包含多个端点，每个端点都有一个唯一的端点地址和传输类型。

主机通过端点地址来选择要与之通信的端点，通过传输类型来确定数据传输的方式，如控制传输、批量传输、中断传输和等时传输。

linux 设备树usb相关解读摘要：1.Linux设备树概述B设备在Linux系统中的识别与使用3.Linux系统中的USB设备驱动程序4.详细解析i2c-adapter和设备树的关联5.Linux系统中的USB设备管理正文：一、Linux设备树概述Linux设备树（Device Tree，简称DTS）是一种描述硬件资源的数据结构，它起源于Open Firmware项目。

在Linux系统中，设备树提供了一种标准的方式来描述硬件设备及其属性，使得操作系统能够正确地识别和管理硬件设备。

二、USB设备在Linux系统中的识别与使用在Linux系统中，USB设备的识别和使用主要依赖于设备树。

当USB设备插入电脑时，Linux系统会根据设备树中的信息来识别设备类型、驱动程序等信息。

此外，Linux系统还提供了umount、df等命令来查看和操作USB设备。

三、Linux系统中的USB设备驱动程序在Linux系统中，USB设备驱动程序负责管理和操作USB设备。

驱动程序根据设备树中的信息来初始化设备，进行数据传输和控制。

对于不同的USB设备，Linux系统提供了相应的驱动程序，如i2c-adapter。

四、详细解析i2c-adapter和设备树的关联i2c-adapter是Linux系统中一种常用的USB设备驱动程序。

在设备树中，i2c-adapter关联到i2c总线，负责管理i2c设备。

i2c-adapter的probe 部分会在/dev目录下创建文件，用于与设备进行通信。

五、Linux系统中的USB设备管理Linux系统提供了丰富的命令和工具来管理USB设备，如usb-util、lsusb 等。

用户可以通过这些命令查看USB设备的状态、信息等。

此外，Linux系统还支持通过设备树动态加载和卸载USB设备驱动程序，使得USB设备的管理更加灵活。

总结：Linux系统中的USB设备管理依赖于设备树和驱动程序。

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 USB驱动框架分析USB（Universal Serial Bus）是一种通用的串行总线标准，其可用于连接计算机系统与外部设备（键盘、鼠标、闪存等）。

为了实现 Linux 系统下的 USB 设备驱动程序，内核提供了一个 USB 驱动框架，本文将对该框架进行分析。

USB 设备的基本组成部分在分析 USB 驱动框架之前，有必要对 USB 设备和 USB 数据传输方式进行简要介绍。

USB 设备USB 设备由三个部分组成：B 总线USB 总线负责提供电力和数据传输，是 USB 设备和主机之间连接的物理媒介。

B 主控USB 主控负责对 USB 总线进行管理，发现并控制所连接的 USB 设备，并负责执行 USB 设备和主机之间的数据传输。

B 设备USB 设备通常由芯片组和外部电路组成，其中芯片组通常由 USB 控制器和设备特定的控制器芯片组成。

USB 数据传输方式USB 设备和主机之间的数据传输方式包括：1.控制传输用于控制和配置设备，如读取设备描述符和配置。

2.批量传输用于大数据块的传输，如打印机的数据传输。

3.中断传输用于周期性的小数据块传输，如鼠标和键盘输入。

4.等时传输用于实时传输，如音频数据传输。

USB 驱动框架内核提供的 USB 驱动框架可使开发者对 USB 设备进行驱动，其主要包括以下组件：B subsystem（USB 子系统）USB subsystem 是一个内核子系统，其主要负责 USB 总线管理、USB 主控管理、USB 设备驱动等工作。

B core（USB 核心）USB core 是 USB 驱动框架的核心，其主要负责识别和配置 USB 设备，并提供USB 核心驱动和 USB 设备驱动之间的接口。

B 核心驱动和 USB 设备驱动USB 核心驱动和 USB 设备驱动是相互独立的模块，它们共同构成了 USB 驱动框架。

USB 核心驱动主要负责 USB 设备的底层管理，USB 设备驱动则负责处理读写操作等操作。

Linux下USB驱动详解（HOST）USB驱动分为两块，一块是USB的bus驱动，这个东西，Linux内核已经做好了，我们可以不管，我们只需要了解它的功能。

形象的说，USB的bus驱动相当于铺出一条路来，让所有的信息都可以通过这条USB通道到达该到的地方，这部分工作由usb_core(drivers/usb/usb.c)来完成。

当USB设备接到USB控制器接口时，usb_core就检测该设备的一些信息，如生产厂商的ID(VID)和产品的ID(PID)，或者是设备所属的class、subclass跟protocol，以便确定应该调用哪一个驱动处理该设备。

里面复杂细节我们不用管，我们要做的是另一块工作——usb的设备驱动。

也就是说，我们就等着usb_core告诉我们要工作了，我们才工作。

OHCI（Open Host Controller Interface）是支持USB1.1的标准，但它不仅仅是针对USB，还支持其他的一些接口，比如它还支持Apple的火线（Firewire，IEEE 1394）接口。

与UHCI 相比，OHCI的硬件复杂，硬件做的事情更多，所以实现对应的软件驱动的任务，就相对较简单。

主要用于非x86的USB，如扩展卡、嵌入式开发板的USB主控。

本文也是基于OHCI来介绍usb设备驱动的。

USB从设备的分类可以从USB设备接口描述符（Standard Interface Descriptor）对应的的bInterfaceClass这一个byte得到。

bInterfaceClass的典型代码为1，2，3，6，7，8，9，10，11，255。

分别代表的意思为1－audio：表示一个音频设备。

2－communication device：通讯设备，如电话，moden等等。

3－HID：人机交互设备，如键盘，鼠标等。

6－image图象设备，如扫描仪，摄像头等，有时数码相机也可归到这一类。

7－打印机类。

B骨架在Linux kernel源码目录中driver/USB/USB-skeleton.c为我们提供了一个最基础的USB驱动程序。

我们称为USB骨架。

通过它我们仅需要修改极少的部分，就可以完成一个USB设备的驱动。

我们的USB驱动开发也是从她开始的。

那些linux下不支持的USB设备几乎都是生产厂商特定的产品。

如果生产厂商在他们的产品中使用自己定义的协议，他们就需要为此设备创建特定的驱动程序。

当然我们知道，有些生产厂商公开他们的USB协议，并帮助Linux驱动程序的开发，然而有些生产厂商却根本不公开他们的USB协议。

因为每一个不同的协议都会产生一个新的驱动程序，所以就有了这个通用的USB驱动骨架程序，它是以pci 骨架为模板的。

如果你准备写一个linux驱动程序，首先要熟悉USB协议规范，在USB主页上有它的帮助。

一些比较典型的驱动可以在上面发现，同时还介绍了USB urbs 的概念，而这个是USB驱动程序中最基本的内容。

Linux USB 驱动程序需要做的第一件事情就是在Linux USB 子系统里注册，并提供一些相关信息，例如这个驱动程序支持那种设备，当被支持的设备从系统插入或拔出时，会有哪些动作。

所有这些信息都传送到USB 子系统中，在USB骨架驱动程序中是这样来表示的：变量name是一个字符串，它对驱动程序进行描述；probe 和disconnect 是函数指针，当设备与在id_table 中变量信息匹配时，此函数被调用；fops和minor变量是可选的。

大多数USB驱动程序往往都会钩住另外一个驱动系统，例如SCSI、网络或者tty子系统。

这些驱动程序在其他驱动系统中注册，同时任何用户空间的交互操作通过那些接口提供，比如我们把SCSI设备驱动作为我们USB驱动所钩住的另外一个驱动系统，那么我们此USB设备的read、write等操作，就相应按SCSI 设备的read、write函数进行访问。

linux usb设备驱动和通信原理Linux USB设备驱动和通信原理一、引言USB（Universal Serial Bus，通用串行总线）是一种用于连接计算机和外部设备的常见接口标准。

在Linux系统中，USB设备驱动是实现计算机与USB设备通信的关键。

本文将介绍Linux USB设备驱动的工作原理、通信过程以及相关概念。

二、USB设备驱动的工作原理1. 设备注册在Linux系统中，USB设备驱动是通过注册机制实现的。

当插入一个USB设备时，系统会自动扫描设备并加载相应的驱动程序。

驱动程序需要向系统注册设备的Vendor ID（厂商识别码）和Product ID（产品识别码），以便系统能够正确识别设备并加载相应的驱动。

2. 设备与驱动的匹配系统通过设备的Vendor ID和Product ID来匹配已注册的驱动程序。

一旦匹配成功，系统就会加载相应的驱动程序，并为设备分配一个唯一的设备文件，例如/dev/usb/0。

3. 驱动初始化驱动程序在加载后会进行初始化操作。

这包括分配内存、注册设备、设置设备的操作接口等。

初始化完成后，驱动程序就可以与设备进行通信。

4. 设备操作驱动程序通过操作设备文件来与USB设备进行通信。

设备文件提供了一组接口函数，可以用于读取设备数据、写入设备数据、控制设备等。

三、USB设备通信原理1. 控制传输控制传输是USB设备通信的基础。

它由主机发起，用于设备的配置和控制。

控制传输分为控制请求和控制数据阶段。

控制请求阶段用于发送控制命令和参数，而控制数据阶段用于传输数据。

2. 中断传输中断传输主要用于传输实时或周期性的数据。

设备会定期向主机发送中断包，主机接收后可以做出相应的处理。

中断传输适用于一些对实时性要求较高的设备，如鼠标、键盘等。

3. 批量传输批量传输用于传输大量的数据，但对实时性要求不高。

批量传输可以分为批量读和批量写两种方式。

批量传输适用于一些需要大量数据传输的设备，如打印机、存储设备等。

Linux usb 设备驱动四篇文章一、Linux USB 驱动编程指导：/Par/arch/usb/usbdoc/二、Linux USB驱动框架分析Linux USB驱动框架分析说明：本来也想自己总结一下USB驱动，但是在网上看到这篇文章，感觉我想说的它已经说了，而我没想到要说的，它也已经说了，所以就转载了！如果只是写一个简单的USB驱动，我想看完这篇文章就应该不成问题了！Linux USB驱动框架分析（一）初次接触与OS相关的设备驱动编写，感觉还挺有意思的，为了不至于忘掉看过的东西，笔记跟总结当然不可缺，更何况我决定为嵌入式卖命了。

好，言归正传，我说一说这段时间的收获，跟大家分享一下Linux的驱动开发。

但这次只先针对Linux的USB子系统作分析，因为周五研讨老板催货。

当然，还会顺带提一下其他的驱动程序写法。

事实上，Linux的设备驱动都遵循一个惯例——表征驱动程序（用driver更贴切一些，应该称为驱动器比较好吧）的结构体，结构体里面应该包含了驱动程序所需要的所有资源。

用术语来说，就是这个驱动器对象所拥有的属性及成员。

由于Linux的内核用c来编写，所以我们也按照这种结构化的思想来分析代码，但我还是希望从OO的角度来阐述这些细节。

这个结构体的名字有驱动开发人员决定，比如说，鼠标可能有一个叫做mouse_dev的struct，键盘可能由一个keyboard_dev的struct（dev for device，我们做的只是设备驱动）。

而这次我们来分析一下Linux 内核源码中的一个usb-skeleton（就是usb驱动的骨架咯），自然，他定义的设备结构体就叫做usb-skel：struct usb_skel {struct usb_device * udev; /* the usb device for this device */struct usb_interface * interface; /* the interface for this device */struct semaphore limit_sem; /* limiting the number of writes in progress */unsigned char * bulk_in_buffer; /* the buffer to receive data */size_t bulk_in_size; /* the size of the receive buffer */__u8 bulk_in_endpointAddr; /* the address of the bulk in endpoint */__u8 bulk_out_endpointAddr; /* the address of the bulk out endpoint */struct kref kref;};这里我们得补充说明一下一些USB的协议规范细节。

Linux下的硬件驱动——USB设备（上）（驱动配置部分）USB设备越来越多，而Linux在硬件配置上仍然没有做到完全即插即用，对于Linux怎样配置和使用他们，也越来越成为困扰我们的一大问题。

本文着力从Linux系统下设备驱动的架构，去阐述怎样去使用和配置以及怎样编制USB设备驱动。

对于一般用户，可以使我们明晰Linux设备驱动方式，为更好地配置和使用USB设备提供了方便；而对于希望开发Linux系统下USB设备驱动的程序员，提供了初步学习USB驱动架构的机会。

前言USB是英文"Universal Serial Bus"的缩写，意为"通用串行总线"。

是由Compaq(康柏)、DEC、IBM、Intel、NEC、微软以及Northern Telecom（北方电讯）等公司于1994年11月共同提出的，主要目的就是为了解决接口标准太多的弊端。

USB使用一个4针插头作为标准插头，并通过这个标准接头，采用菊花瓣形式把所有外设连接起来，它采用串行方式传输数据，目前最大数据传输率为12Mbps, 支持多数据流和多个设备并行操作，允许外设热插拔。

目前USB接口虽然只发展了2代（USB1.0/1.1，USB2.0），但是USB综合了一个多平台标准的所有优点 -- 包括降低成本，增加兼容性，可连接大量的外部设备，融合先进的功能和品质。

使其逐步成为PC接口标准，进入了高速发展期。

那么对于使用Linux系统，正确支持和配置常见的USB设备，就是其使用必不可少的关键一步。

相关技术基础模块（驱动程序）模块（module）是在内核空间运行的程序，实际上是一种目标对象文件，没有链接，不能独立运行，但是可以装载到系统中作为内核的一部分运行，从而可以动态扩充内核的功能。

模块最主要的用处就是用来实现设备驱动程序。

Linux下对于一个硬件的驱动，可以有两种方式：直接加载到内核代码中，启动内核时就会驱动此硬件设备。

Linux下USB驱动基础/uid-9185047-id-445196.html2011-03-30USB是主机和外围设备之间的一种连接。

USB最初是为了替代各种各样的不同的接口的低速总线而设计的。

（例如：串口，并口，键盘连接等）。

它以单一类型的总线连接各种不同类型的设备。

USB拓扑机构不是以总线方式的。

而是一棵由几个点对点的连接构成的树。

连接线由4根电缆组成（电源，地线，两个数据线）USB主控制器（Host Controller）负责询问每一个USB设备是否有数据需要发送。

也就是说：一个USB设备在没有主控制器要求的情况下是不能发送数据的。

USB协议规范定义了一套任何特定类型的设备都可以遵循的标准。

如果一个设备遵循该设备，就不需要一个特殊的驱动程序。

这些不同的特定类型称之为类（class）.例如：存储设备，键盘，鼠标，游戏杆，网络设备等。

对于不符合这些类的其他设备。

则需要对此设备编写特定driver.USB设备构成：Linux Kernel提供了USB Core来处理大部分USB的复杂性。

写USB驱动，Sam觉得就是把USB硬件设备和USB Core之间给沟通起来。

USB协议把一个硬件USB设备用以下各个定义勾画出来。

概念一. USB 端点（endpoint）USB endpoint只能往一个方向传送数据。

从主机到设备（输出Endpoint）或从设备到主机（输入Endpoint）。

一个Endpoint可以看作一个单向的管道。

有四种类型Endpoint，他们的区别在于传送数据的方式：控制Endpoint：用来控制对USB设备不同部分的访问。

他们通常用于配置设备，获取设备信息，发送命令到设备，或者获取设备的状态报告。

每个USB设备都有一个名为：Endpoint0的控制Endpoint。

USB Core使用该Endpoint0在插入时进行设备的配置。

中断Endpoint：每当USB主控制器要求设备传输数据时，中断Endpoint就以一个固定的速率来传送少量的数据。

linuxusb设备驱动和接口驱动/uid-9185047-id-445204.html2011-04-11每个usb设备，都可能会有多个接口，每个接口都实现了一个功能。

在linux上，每个usb设备是一个device，而每个接口也同样是一个device。

所有的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,};但是每一个接口所对应的驱动则是单独的驱动。

我们看一下usb设备和usb接口的定义。

如下：struct usb_device {int devnum;char devpath[16];u32 route;enum usb_device_state state;enum usb_device_speed speed;struct usb_tt *tt;int ttport;unsigned int toggle[2];struct usb_device *parent;struct usb_bus *bus;struct usb_host_endpoint ep0;struct device dev;struct usb_device_descriptor descriptor; struct usb_host_config *config;struct usb_host_config *actconfig; struct usb_host_endpoint *ep_in[16]; struct usb_host_endpoint *ep_out[16];char **rawdescriptors;unsigned short bus_mA;u8 portnum;u8 level;unsigned can_submit:1;unsigned persist_enabled:1; unsigned have_langid:1;unsigned authorized:1;unsigned authenticated:1;unsigned wusb:1;int string_langid;/* static strings from the device */char *product;char *manufacturer;char *serial;struct list_head filelist;#ifdef CONFIG_USB_DEVICE_CLASSstruct device *usb_classdev;#endif#ifdef CONFIG_USB_DEVICEFSstruct dentry *usbfs_dentry;#endifint maxchild;struct usb_device *children[USB_MAXCHILDREN];u32 quirks;atomic_t urbnum;unsigned long active_duration;#ifdef CONFIG_PMunsigned long last_busy;int autosuspend_delay;unsigned long connect_time;unsigned do_remote_wakeup:1;unsigned reset_resume:1;#endifstruct wusb_dev *wusb_dev;int slot_id;};struct usb_interface {/* array of alternate settings for this interface,* stored in no particular order */struct usb_host_interface *altsetting;struct usb_host_interface *cur_altsetting; /* the currently* active alternate setting */unsigned num_altsetting; /* number of alternate settings *//* If there is an interface association descriptor then it will list * the associated interfaces */struct usb_interface_assoc_descriptor *intf_assoc;int minor; /* minor number this interface is* bound to */enum usb_interface_condition condition; /* state of binding */unsigned sysfs_files_created:1; /* the sysfs attributes exist */ unsigned ep_devs_created:1; /* endpoint "devices" exist */ unsigned unregistering:1; /* unregistration is in progress */ unsigned needs_remote_wakeup:1; /* driver requires remote wakeup */unsigned needs_altsetting0:1; /* switch to altsetting 0 is pending */unsigned needs_binding:1; /* needs delayed unbind/rebind */unsigned reset_running:1;unsigned resetting_device:1; /* true: bandwidth alloc after reset */struct device dev; /* interface specific device info */struct device *usb_dev;atomic_t pm_usage_cnt; /* usage counter for autosuspend */ struct work_struct reset_ws; /* for resets in atomic context */ };我们可以看到，这两个定义里都有struct device。