usblinux驅動架構

Ⅰ 怎樣寫linux下的USB設備驅動程序

USB驅動程序基礎
在動手寫USB驅動程序這前，讓我們先看看寫的驅動程序在內核中的結構，如下圖：

USB通信最基本的形式是通過端點（USB端點分中斷、批量、等時、控制四種，每種用途不同），USB端點只能往一個方向傳送數據，從主機到設備或者從設備到主機，端點可以看作是單向的管道（pipe）。所以我們可以這樣認為：設備通常具有一個或者更多的配置，配置經常具有一個或者更多的介面，介面通常具有一個或者更多的設置，介面沒有或具有一個以上的端點。驅動程序把驅動程序對象注冊到USB子系統中，稍後再使用製造商和設備標識來判斷是否已經安裝了硬體。USB核心使用一個列表（是一個包含製造商ID和設備號ID的一個結構體）來判斷對於一個設備該使用哪一個驅動程序，熱插撥腳本使用它來確定當一個特定的設備插入到系統時該自動裝載哪一個驅動程序。
上面我們簡要說明了驅動程序的基本理論，在寫一個設備驅動程序之前，我們還要了解以下兩個概念：模塊和設備文件。
模塊：是在內核空間運行的程序，實際上是一種目標對象文件，沒有鏈接，不能獨立運行，但是可以裝載到系統中作為內核的一部分運行，從而可以動態擴充內核的功能。模塊最主要的用處就是用來實現設備驅動程序。Linux下對於一個硬體的驅動，可以有兩種方式：直接載入到內核代碼中，啟動內核時就會驅動此硬體設備。另一種就是以模塊方式，編譯生成一個.ko文件(在2.4以下內核中是用.o作模塊文件，我們以2.6的內核為准，以下同)。當應用程序需要時再載入到內核空間運行。所以我們所說的一個硬體的驅動程序，通常指的就是一個驅動模塊。
設備文件：對於一個設備，它可以在/dev下面存在一個對應的邏輯設備節點，這個節點以文件的形式存在，但它不是普通意義上的文件，它是設備文件，更確切的說，它是設備節點。這個節點是通過mknod命令建立的，其中指定了主設備號和次設備號。主設備號表明了某一類設備，一般對應著確定的驅動程序；次設備號一般是區分不同屬性，例如不同的使用方法，不同的位置，不同的操作。這個設備號是從/proc/devices文件中獲得的，所以一般是先有驅動程序在內核中，才有設備節點在目錄中。這個設備號（特指主設備號）的主要作用，就是聲明設備所使用的驅動程序。驅動程序和設備號是一一對應的，當你打開一個設備文件時，操作系統就已經知道這個設備所對應的驅動程序。對於一個硬體，Linux是這樣來進行驅動的：首先，我們必須提供一個.ko的驅動模塊文件。我們要使用這個驅動程序，首先要載入它，我們可以用insmod
xxx.ko，這樣驅動就會根據自己的類型（字元設備類型或塊設備類型，例如滑鼠就是字元設備而硬碟就是塊設備）向系統注冊，注冊成功系統會反饋一個主設備號，這個主設備號就是系統對它的唯一標識。驅動就是根據此主設備號來創建一個一般放置在/dev目錄下的設備文件。在我們要訪問此硬體時，就可以對設備文件通過open、read、write、close等命令進行。而驅動就會接收到相應的read、write操作而根據自己的模塊中的相應函數進行操作了。

USB驅動程序實踐
了解了上述理論後，我們就可以動手寫驅動程序，如果你基本功好，而且寫過linux下的硬體驅動，USB的硬體驅動和pci_driver很類似，那麼寫USB的驅動就比較簡單了，如果你只是大體了解了linux的硬體驅動，那也不要緊，因為在linux的內核源碼中有一個框架程序可以拿來借用一下，這個框架程序在/usr/src/~（你的內核版本，以下同）/drivers/usb下，文件名為usb-skeleton.c。寫一個USB的驅動程序最基本的要做四件事：驅動程序要支持的設備、注冊USB驅動程序、探測和斷開、提交和控制urb（USB請求塊）（當然也可以不用urb來傳輸數據，下文我們會說到）。
驅動程序支持的設備：有一個結構體struct
usb_device_id，這個結構體提供了一列不同類型的該驅動程序支持的USB設備，對於一個只控制一個特定的USB設備的驅動程序來說，struct
usb_device_id表被定義為：
/* 驅動程序支持的設備列表 */
static struct usb_device_id
skel_table [] = {
{ USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID)
},
{ } /* 終止入口 */
};
MODULE_DEVICE_TABLE (usb,
skel_table);
對於PC驅動程序，MODULE_DEVICE_TABLE是必需的，而且usb必需為該宏的第一個值，而USB_SKEL_VENDOR_ID和USB_SKEL_PRODUCT_ID就是這個特殊設備的製造商和產品的ID了，我們在程序中把定義的值改為我們這款USB的，如：
/*
定義製造商和產品的ID號 */
#define USB_SKEL_VENDOR_ID 0x1234
#define
USB_SKEL_PRODUCT_ID
0x2345
這兩個值可以通過命令lsusb，當然你得先把USB設備先插到主機上了。或者查看廠商的USB設備的手冊也能得到，在我機器上運行lsusb是這樣的結果：
Bus
004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 1234:2345 Abc Corp.

Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID
0000:0000
得到這兩個值後把它定義到程序里就可以了。
注冊USB驅動程序：所有的USB驅動程序都必須創建的結構體是struct
usb_driver。這個結構體必須由USB驅動程序來填寫，包括許多回調函數和變數，它們向USB核心代碼描述USB驅動程序。創建一個有效的struct
usb_driver結構體，只須要初始化五個欄位就可以了，在框架程序中是這樣的：
static struct usb_driver skel_driver
= {
.owner = THIS_MODULE,
.name = "skeleton",

.probe = skel_probe,
.disconnect = skel_disconnect,

.id_table = skel_table,
};

Ⅱ USB驅動的組成有哪些

在USB規范中把USB分為五個部分：控制器、控制器驅動程序、USB晶元驅動程序、USB設備和針對不同USB設備的客戶驅動程序。第一、 USB晶元驅動程序：這部分組件主要是可以提供對USB的支持。第二、 USB控制器驅動程序：這部分主要是在控制器和USB設備之間建立通信信道。第三、 USB設備：這部分組件包括和PC相連的USB外圍設備，主要分為：設備本身可以再接上其它的USB外圍設備，另外設備本身不能再連接其它外圍設備。即集線器和設備。也可以說集線器是帶有連接其它外圍設備的USB埠，設備是連接在計算機上的用語完成特定功能而且符合USB規范的設備單元。第四、 USB控制器：這部分主要負責執行由USB控制器驅動程序發出的命令。第五、 USB設備驅動程序：這部分組件主要是用來驅動USB設備的程序，一般來說這是由操作系統或者是USB設備製造商提供

Ⅲ Linux驅動的軟體架構

Linux不是為了某單一電路板而設計的操作系統，它可以支持約30種體系結構下一定數量的硬體，因此，它的驅動架構很顯然不能像RTOS下或者無操作系統下那麼小兒科的做法。Linux設備驅動非常重視軟體的可重用和跨平台能力。譬如，如果我們寫下一個DM9000網卡的驅動，Linux的想法是這個驅動應該最好一行都不要改就可以在任何一個平台上跑起來。
#ifdef BOARD_Xxx
#define DM9000_BASE 0x100oo#define DM900o_IRQ 8
#elif defined(BOARD_YYY)#define DM9000_BASEox200oo#define DM90oo_IRo 7
#elif defined (BOARD_Z2Z)#define DM9000_BASEox3000o#define DM9o0o_IRQ9...
#endif
上述代碼主要有如下問題:
1)此段代碼看起來面目可憎，如果有100個板子，就要iflelse 100次，到了第101個板子，又得重新加ifelse。代碼進行著簡單的「復制—粘貼」，「復制—粘貼」式的簡單重復通常意味著代碼編寫者的水平很差。
2）非常難做到一個驅動支持多個設備，如果某個電路板上有兩個DM9000網卡，則DM9000_BASE這個宏就不夠用了，此時勢必要定義出來DM9000_BASE 1、DM9000_BASE 2、DM9000_IRQ 1、DM9000_IRQ 2類的宏;定義了DM9000_BASE 1、DM9000_BASE2後，如果又有第3個DM9000網卡加到板子上，前面的代碼就又不適用了。
3）依賴於make menuconfig選擇的項目來編譯內核，因此，在不同的硬體平台下要依賴於所選擇的BOARD_XXX、BOARD_YYY選項來決定代碼邏輯。這不符合ARM Linux 3.x一個映像適用於多個硬體的目標。實際上，我們可能同時選擇了BOARD_XXX、BOARD_YYY、BOARD_ZZZ。
我們按照上面的方法編寫代碼的時候，相信自己編著編著也會覺得奇怪，代碼不好。這個時候，我們有沒有辦法把設備端的信息從驅動裡面剝離出來，讓驅動以某種標准方法拿到這些平台信息呢Linux匯流排、設備和驅動模型實際上可以做到這一點，驅動就可以放之四海而皆準了。

Ⅳ linux主機側與設備側USB驅動

USB採用樹形拓撲結構，主機側和設備側的USB控制器分別稱為主機控制器（(Host Controller）和USB設備控制器(UDC)，每條匯流排上只有一個主機控制器，負責協調主機和設備間的通信，而設備不能主動向主機發送任何消息。

在Linux系統中，USB驅動可以從兩個角度去觀察，一個角度是主機側，一個角度是設備側。從上圖主機側去看，在Linux驅動中，處於USB驅動最底層的是USB主機控制器硬體，在其上運行的是USB主機控制器驅動，在主機控制器上的為USB核心層，再上層為USB設備驅動層(插入主機上的U盤、滑鼠、USB轉串口等設備驅動）。因此，在主機側的層次結構中，要實現的USB驅動包括兩類:USB主機控制器驅動和USB設備驅動，前者控制插入其中的USB設備，後者控制USB設備如何與主機通信。Linux內核中的USB核心負責USB驅動管理和協議處理的主要工作。主機控制器驅動和設備驅動之間的USB核心非常重要，其功能包括:通過定義一些數據結構、宏和功能函數，向上為設備驅動提供編程介面，向下為USB主機控制器驅動提供編程介面;維護整個系統的USB設備信息;完成設備熱插拔控制、匯流排數據傳輸控制等。

Ⅳ Linux USB主機控制器驅動的整體結構

USB主機控制器有這些規格:OHCI (Open Host Controller Interface）、UHCI (Universal HostController Interface)、EHCI (Enhanced Host Controller Interface）和xHCI (eXtensible Host ControllerInterface)。OHCI驅動程序用來為非PC系統上以及帶有SiS和ALi晶元組的PC主板上的USB晶元提供支持。UHCI驅動程序多用來為大多數其他PC主板（包括Intel和Via）上的USB晶元提供支持。EHCI由USB2.0規范所提出，它兼容於OHCI和UHCI。由於UHCI的硬體線路比OHCI簡單，所以成本較低，但需要較復雜的驅動程序，CPU負荷稍重。xHCI，即可擴展的主機控制器介面是Intel公司開發的一個USB主機控制器介面，它目前主要是面向USB 3.0的，同時它也支持USB 2.0及以下的設備。
1.主機控制器驅動
在Linux內核中，用usb hed結構體描述USB主機控制器驅動，它包含USB主機控制器的「家務」信息、硬體資源、狀態描述和用於操作主機控制器的hc_driver。
2.EHCI主機控制器驅動
EHCI HCD驅動屬於HCD驅動的實例，它定義了一個ehci_hed結構體，通常作為代碼清單16.6定義的usb_hed結構體的私有數據(hed_priv)，這個結構體的定義位於rivers/usb/host/ehci.h中。

Ⅵ 如何簡化linux usb 驅動 實驗報告

《LINUX設備驅動程序》

USB骨架程序（usb-skeleton），是USB驅動程序的基礎，通過對它源碼的學習和理解，可以使我們迅速地了解USB驅動架構，迅速地開發我們自己的USB硬體的驅動。
前言
在上篇《Linux下的硬體驅動--USB設備（上）（驅動配製部分）》中，我們知道了在Linux下如何去使用一些最常見的USB設備。但對於做系統設計的程序員來說，這是遠遠不夠的，我們還需要具有驅動程序的閱讀、修改和開發能力。在此下篇中，就是要通過簡單的USB驅動的例子，隨您一起進入 USB驅動開發的世界。
USB驅動開發
在掌握了USB設備的配置後，對於程序員，我們就可以嘗試進行一些簡單的USB驅動的修改和開發了。這一段落，我們會講解一個最基礎USB框架的基礎上，做兩個小的USB驅動的例子。
USB骨架
在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骨架驅動程序中是這樣來表示的：
static struct usb_driver skel_driver = {
name: "skeleton",
probe: skel_probe,
disconnect: skel_disconnect,
fops: &skel_fops,
minor: USB_SKEL_MINOR_BASE,
id_table: skel_table,
};
變數name是一個字元串，它對驅動程序進行描述。probe 和disconnect 是函數指針，當設備與在id_table 中變數信息匹配時，此函數被調用。
fops和minor變數是可選的。大多usb驅動程序鉤住另外一個驅動系統，例如SCSI，網路或者tty子系統。這些驅動程序在其他驅動系統中注冊，同時任何用戶空間的交互操作通過那些介面提供，比如我們把SCSI設備驅動作為我們USB驅動所鉤住的另外一個驅動系統，那麼我們此USB設備的 read、write等操作，就相應按SCSI設備的read、write函數進行訪問。但是對於掃描儀等驅動程序來說，並沒有一個匹配的驅動系統可以使用，那我們就要自己處理與用戶空間的read、write等交互函數。Usb子系統提供一種方法去注冊一個次設備號和file_operations函數指針，這樣就可以與用戶空間實現方便地交互。

Ⅶ 怎樣寫linux下的USB設備驅動程序

寫一個USB的驅動程序最 基本的要做四件事：驅動程序要支持的設備、注冊USB驅動程序、探測和斷開、提交和控制urb（USB請求塊）
驅動程序支持的設備：有一個結構體struct usb_device_id，這個結構體提供了一列不同類型的該驅動程序支持的USB設備，對於一個只控制一個特定的USB設備的驅動程序來說，struct usb_device_id表被定義為：
/* 驅動程序支持的設備列表 */
static struct usb_device_id skel_table [] = {
{ USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID) },
{ } /* 終止入口 */
};
MODULE_DEVICE_TABLE (usb, skel_table);
對 於PC驅動程序，MODULE_DEVICE_TABLE是必需的，而且usb必需為該宏的第一個值，而USB_SKEL_VENDOR_ID和 USB_SKEL_PRODUCT_ID就是這個特殊設備的製造商和產品的ID了，我們在程序中把定義的值改為我們這款USB的，如：
/* 定義製造商和產品的ID號 */
#define USB_SKEL_VENDOR_ID 0x1234
#define USB_SKEL_PRODUCT_ID 0x2345
這兩個值可以通過命令lsusb，當然你得先把USB設備先插到主機上了。或者查看廠商的USB設備的手冊也能得到，在我機器上運行lsusb是這樣的結果：
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 1234:2345 Abc Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
得到這兩個值後把它定義到程序里就可以了。
注冊USB驅動程序：所 有的USB驅動程序都必須創建的結構體是struct usb_driver。這個結構體必須由USB驅動程序來填寫，包括許多回調函數和變數，它們向USB核心代碼描述USB驅動程序。創建一個有效的 struct usb_driver結構體，只須要初始化五個欄位就可以了，在框架程序中是這樣的：
static struct usb_driver skel_driver = {
.owner = THIS_MODULE,
.name = "skeleton",
.probe = skel_probe,
.disconnect = skel_disconnect,
.id_table = skel_table,
};
探測和斷開：當 一個設備被安裝而USB核心認為該驅動程序應該處理時，探測函數被調用，探測函數檢查傳遞給它的設備信息，確定驅動程序是否真的適合該設備。當驅動程序因 為某種原因不應該控制設備時，斷開函數被調用，它可以做一些清理工作。探測回調函數中，USB驅動程序初始化任何可能用於控制USB設備的局部結構體，它 還把所需的任何設備相關信息保存到一個局部結構體中，
提交和控制urb：當驅動程序有數據要發送到USB設備時（大多數情況是在驅動程序的寫函數中），要分配一個urb來把數據傳輸給設備：
/* 創建一個urb,並且給它分配一個緩存*/
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
retval = -ENOMEM;
goto error;
}
當urb被成功分配後，還要創建一個DMA緩沖區來以高效的方式發送數據到設備，傳遞給驅動程序的數據要復制到這塊緩沖中去：
buf = usb_buffer_alloc(dev->udev, count, GFP_KERNEL, &urb->transfer_dma);
if (!buf) {
retval = -ENOMEM;
goto error;
}

if (_from_user(buf, user_buffer, count)) {
retval = -EFAULT;
goto error;
}
當數據從用戶空間正確復制到局部緩沖區後，urb必須在可以被提交給USB核心之前被正確初始化：
/* 初始化urb */
usb_fill_bulk_urb(urb, dev->udev,
usb_sndbulkpipe(dev->udev, dev->bulk_out_endpointAddr),
buf, count, skel_write_bulk_callback, dev);
urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
然後urb就可以被提交給USB核心以傳輸到設備了：
/* 把數據從批量OUT埠發出 */
retval = usb_submit_urb(urb, GFP_KERNEL);
if (retval) {
err("%s - failed submitting write urb, error %d", __FUNCTION__, retval);
goto error;
}
當urb被成功傳輸到USB設備之後，urb回調函數將被USB核心調用，在我們的例子中，我們初始化urb，使它指向skel_write_bulk_callback函數，以下就是該函數：
static void skel_write_bulk_callback(struct urb *urb, struct pt_regs *regs)
{
struct usb_skel *dev;

dev = (struct usb_skel *)urb->context;

if (urb->status &&
!(urb->status == -ENOENT ||
urb->status == -ECONNRESET ||
urb->status == -ESHUTDOWN)) {
dbg("%s - nonzero write bulk status received: %d",
__FUNCTION__, urb->status);
}

/* 釋放已分配的緩沖區 */
usb_buffer_free(urb->dev, urb->transfer_buffer_length,
urb->transfer_buffer, urb->transfer_dma);
}
有時候USB驅動程序只是要發送或者接收一些簡單的數據，驅動程序也可以不用urb來進行數據的傳輸，這是里涉及到兩個簡單的介面函數：usb_bulk_msg和usb_control_msg ，在這個USB框架程序里讀操作就是這樣的一個應用：
/* 進行阻塞的批量讀以從設備獲取數據 */
retval = usb_bulk_msg(dev->udev,
usb_rcvbulkpipe(dev->udev, dev->bulk_in_endpointAddr),
dev->bulk_in_buffer,
min(dev->bulk_in_size, count),
&count, HZ*10);

/*如果讀成功，復制到用戶空間 */
if (!retval) {
if (_to_user(buffer, dev->bulk_in_buffer, count))
retval = -EFAULT;
else
retval = count;
}
usb_bulk_msg介面函數的定義如下：
int usb_bulk_msg(struct usb_device *usb_dev,unsigned int pipe,
void *data,int len,int *actual_length,int timeout);
其參數為：
struct usb_device *usb_dev：指向批量消息所發送的目標USB設備指針。
unsigned int pipe：批量消息所發送目標USB設備的特定端點，此值是調用usb_sndbulkpipe或者usb_rcvbulkpipe來創建的。
void *data：如果是一個OUT端點，它是指向即將發送到設備的數據的指針。如果是IN端點，它是指向從設備讀取的數據應該存放的位置的指針。
int len：data參數所指緩沖區的大小。
int *actual_length：指向保存實際傳輸位元組數的位置的指針，至於是傳輸到設備還是從設備接收取決於端點的方向。
int timeout：以Jiffies為單位的等待的超時時間，如果該值為0，該函數一直等待消息的結束。
如果該介面函數調用成功，返回值為0，否則返回一個負的錯誤值。
usb_control_msg介面函數定義如下：
int usb_control_msg(struct usb_device *dev,unsigned int pipe,__u8 request,__u8requesttype,__u16 value,__u16 index,void *data,__u16 size,int timeout)
除了允許驅動程序發送和接收USB控制消息之外，usb_control_msg函數的運作和usb_bulk_msg函數類似，其參數和usb_bulk_msg的參數有幾個重要區別：
struct usb_device *dev：指向控制消息所發送的目標USB設備的指針。
unsigned int pipe：控制消息所發送的目標USB設備的特定端點，該值是調用usb_sndctrlpipe或usb_rcvctrlpipe來創建的。
__u8 request：控制消息的USB請求值。
__u8 requesttype：控制消息的USB請求類型值。
__u16 value：控制消息的USB消息值。
__u16 index：控制消息的USB消息索引值。
void *data：如果是一個OUT端點，它是指身即將發送到設備的數據的指針。如果是一個IN端點，它是指向從設備讀取的數據應該存放的位置的指針。
__u16 size：data參數所指緩沖區的大小。
int timeout：以Jiffies為單位的應該等待的超時時間，如果為0，該函數將一直等待消息結束。
如果該介面函數調用成功，返回傳輸到設備或者從設備讀取的位元組數；如果不成功它返回一個負的錯誤值。
這兩個介面函數都不能在一個中斷上下文中或者持有自旋鎖的情況下調用，同樣，該函數也不能被任何其它函數取消，使用時要謹慎。
我們要給未知的USB設備寫驅動程序，只需要把這個框架程序稍做修改就可以用了，前面我們已經說過要修改製造商和產品的ID號，把0xfff0這兩個值改為未知USB的ID號。
#define USB_SKEL_VENDOR_ID 0xfff0
#define USB_SKEL_PRODUCT_ID 0xfff0
還 有就是在探測函數中把需要探測的介面端點類型寫好，在這個框架程序中只探測了批量（USB_ENDPOINT_XFER_BULK）IN和OUT端點，可 以在此處使用掩碼（USB_ENDPOINT_XFERTYPE_MASK）讓其探測其它的端點類型，驅動程序會對USB設備的每一個介面進行一次探測， 當探測成功後，驅動程序就被綁定到這個介面上。再有就是urb的初始化問題，如果你只寫簡單的USB驅動，這塊不用多加考慮，框架程序里的東西已經夠用 了，這里我們簡單介紹三個初始化urb的輔助函數：
usb_fill_int_urb ：它的函數原型是這樣的：
void usb_fill_int_urb(struct urb *urb,struct usb_device *dev,
unsigned int pipe,void *transfer_buff,
int buffer_length,usb_complete_t complete,
void *context,int interval);
這個函數用來正確的初始化即將被發送到USB設備的中斷端點的urb。
usb_fill_bulk_urb ：它的函數原型是這樣的：
void usb_fill_bulk_urb(struct urb *urb,struct usb_device *dev,
unsigned int pipe,void *transfer_buffer,
int buffer_length,usb_complete_t complete)
這個函數是用來正確的初始化批量urb端點的。
usb_fill_control_urb ：它的函數原型是這樣的：
void usb_fill_control_urb(struct urb *urb,struct usb_device *dev,unsigned int pipe,unsigned char *setup_packet,void *transfer_buffer,int buffer_length,usb_complete_t complete,void *context);
這個函數是用來正確初始化控制urb端點的。
還有一個初始化等時urb的，它現在還沒有初始化函數，所以它們在被提交到USB核心前，必須在驅動程序中手工地進行初始化，可以參考內核源代碼樹下的/usr/src/~/drivers/usb/media下的konicawc.c文件。

Ⅷ Linux網路設備驅動的結構

Linux網路設備驅動程序的體系結構從上到下可以劃分為4層，依次為網路協議介面層、網路設備介面層、提供實際功能的設備驅動功能層以及網路設備與媒介層，這4層的作用如下所示。
1）網路協議介面層向網路層協議提供統一的數據包收發介面，不論上層協議是ARP，還是IP，都通過dev_queue_xmit() 函數發送數據，並通過netif rx ()函數接收數據。這一層的存在使得上層協議獨立於具體的設備。
2）網路設備介面層向協議介面層提供統一的用於描述具體網路設備屬性和操作的結構體net device,該結構體是設備驅動功能層中各函數的容器。實際上，網路設備介面層從宏觀上規劃了具體操作硬體的設備驅動功能層的結構。
3）設備驅動功能層的各函數是網路設備介面層net_device數據結構的具體成員，是驅使網路設備硬體完成相應動作的程序，它通過hard_start_ xmit ()函數啟動發送操作，並通過網路設備上的中斷觸發接收操作。
4）網路設備與媒介層是完成數據包發送和接收的物理實體，包括網路適配器和具體的傳輸媒介，網路適配器被設備驅動功能層中的函數在物理上驅動。對於Linux系統而言，網路設備和媒介都可以是虛擬的。

Ⅸ USB主機控制器驅動的整體結構

前面寫了一些SPI/I2C/RS-485之類的文章，有朋友留言希望能分享一些USB方面的梳理總結，今天就從系統標准層面先來梳理一下。看看有沒有朋友喜歡。先從系統層面來梳理。個人學習，習慣於先從整體上摸個大概，然後再對感興趣的細節逐漸深入。

USB是比較復雜的協議棧，如果發現文章中有錯誤，請幫忙指正。

註：本文主要參考USB2.0規范第4章，將標准中個人認為比較重要的一些點盡量條理清晰的總結出來。我感覺很多朋友可能對於閱讀英文標准有點輕度抗拒，所以整理此文這也是一個起因，希望對朋友們有所幫助。

A/B系列插座規范A/B系列插頭規范電纜尺寸材料規范，這里就不羅列了，知道在哪裡查就可以了。電氣、機械和環境合規性標准接地規范，屏蔽層一定要焊接在插頭的外殼接地點。插座PCB尺寸規范。所以對於有繪制接插件需要的，可以參考6.9節的尺寸。Logo位置線芯顏色規范。USB Logo尺寸規范。協議概述

USB採用主從通訊模式，是一種輪詢匯流排。所有數據傳輸都由主機控制器發起。這是USB標准中最難啃的部分，這里先不總結。

健壯設計

標准關於協議健壯性，又稱魯棒性，做了這幾個方面的設計：

從信號完整性角度：使用差分驅動器、差分接收器和以及對信號線纜的屏蔽處理。差分收發策略主要在抵抗共模干擾方面效果顯著，而屏蔽層則有兩方面的作用：其一，有效降低USB線通過無線電波對外界干擾；其二、能有效隔斷外界無線干擾對USB信號線、電源線的干擾。CRC報文校驗。報文中數據如果出錯，可以檢測出來，可以做相應的處置。熱插拔檢測及對相應硬體設備的系統配置管理。這個設計有助於提升用戶體驗，用戶隨用隨插，而無需關機插拔。利用對數據丟失或數據損壞超時檢測實現通訊自恢復機制，以增強協議的健壯性。對流數據的進行流量控制以確保同步以及底層收發硬體緩沖區管理。數據管道和控制管道分離