Linux子系統系列-USB

最近調查了MUSB的一個問題，將USB這塊的架構簡單梳理了一下，趁熱這次做下記錄，能提綱挈領即可

/*****************************************************************/

目錄

0，背景

1，USB 子系統結構

2，USB 子系統實現

0，背景

以前剛接觸到USB裝置-u盤時，我們每次都得手動尋找新硬體，然後驅動安裝，才能訪問，後來慢慢的隨身碟一插上都能用了，當時很懶，也不去多想其中原理，就覺得真是神奇啊......

以後工作中都和這一類的東西打交道，才發現不光USB，所有其他一些支援即插即拔功能的匯流排，能發揮這種功效，都是中斷（可以算是硬體規範）和一些驅動編程規範起了作用。

硬體規範可以不管任何裝置，只要滿足一些很簡單的介面設計要求，就可以應用在任何場合（剩下的交給驅動了），這也是電腦的loader（可以啟動各種作業系統）的設計原理。

沒有規矩，不成方圓！

沒有規範，沒有驅動！！

USB的規範手冊就描述了一種匯流排，這條匯流排上可以串連很多種裝置（mass storage,keyboards,mice,etc.），通過它多種裝置可以穩定的和host進行通訊。

基於這個規範，Linux核心提供了USB子系統驅動。

需要注意的事，Linux的USB子系統只提供屬於預定義的類別的裝置的驅動，對於那些例外，需要特定的裝置驅動，這裡只是點出。

1，USB 子系統結構

回想大學時候資料結構沒有學好，當時覺得學這些東西不知道拿來做什麼，不能和實際的東西扯上關係，興趣也就江河日下......這是前話，暫且不表了

這裡我們就從描述當一個USB裝置插上主機開始，看USB子系統如何工作，來瞭解它的大致架構：

隨身碟插上電腦，根據USB匯流排的硬體規範，會產生一個中斷給CPU，

CPU根據中斷管理器送過來的中斷號調用相關的中斷函數，如果是一個共用號，這個中斷函數裡面會對共用它的相關硬體的寄存器進行check，看是否有中斷到來，然後，就呼呼的去完成每個硬體裝置要完成的工作了。所有的硬體都遵循一些規範來設計，他們之間的協同工作就變的那麼優美...譬如人與人/社會之間，如果沒有一些規範來約束，就會變得混亂不堪，USB裝置插入調用的中斷函數會發出一個event，來交待在USB 匯流排上來了一個新人，這個event會發給使用者空間的udevd（或mdevd，如果你使用busybox的話），udevd會根據event中的一些資料來插入相應的模組，掛載對應這個裝置的驅動......這個過程簡單描述如下：雖然，而且到目前為止，我也一直這樣認為，USB匯流排和USB裝置使用軟體進行抽象描述起來是非常複雜的，一方面是協議使然，一方面也是因為它們使用太廣泛了，抽象時考慮很太多情況。但是，幸運的是，核心開發人員們抽象出來的核心USB 子系統把很多複雜性都隱藏了（一群讓我們又愛又恨的人啊 :)）。這樣對整個過程趟了一遍，我們就自然而然的對在其中的軟體實現思想和層次來興趣了，這裡我們先總覽一下：

針對這幅圖，為了理解什麼是USB子系統，我們要做以下說明：a) USB 驅動都是誇kernel子系統的，因為最終USB裝置是要通過BLCOCK 或CHAR裝置的方式呈現給我們的，所以我們看到USB Driver之上還有一層。b) USB driver利用USB Core提供的API來簡單優雅的完成驅動工作，這裡USB Core抽象了複雜的USB協議。c) 主機控制器驅動位於USB軟體的最下層，提供主機控制器硬體的抽象，隱藏硬體的細節，在主機控制器之下是物理的USB及所有與之串連的USB裝置。主機控制器驅動只和USB Core進行關聯，USB Core將使用者的請求映射到相關的主機控制器驅動，從而使使用者無需去訪問主機控制器。d) USB Core和USB主機控制器驅動就構成了我們的USB子系統，USB Core負責實現一些核心的功能，例如協議之類，提供一個用於訪問和控制USB硬體的介面，使裝置驅動不用去考慮系統當前使用哪種主機控制器。自從有了USB子系統，寫USB驅動的時候，只需要調用USB Core export的介面，就幾乎能完成所有工作。2，USB 子系統實現2.1 初始化先羅嗦一下USB裝置是如何抽象的：a) 一個USB會由一個或多個configuration來構成b) 一個configuration會由一個或多個Interface來構成c) 一個interface會由一個或多個setting來構成d) 一個interface會包含0或多個endpointUSB裝置和主機的通訊channel被稱為endpoint： Control，Interrupt， Bulk，Isochronousinterface其實就是通過endpoint來呈現的。

一個USB 驅動會跟一個USB裝置的interface綁定

在USB子系統中，usb_device_id這個資料結構被用來匹配USB裝置和相應的驅動。為了使用方便，USB Core會提供一些宏來協助建立這個資料結構。按照約定，這個表會在驅動中export出來（使用MODULE_DEVICE_TABLE宏），在build階段的時候，這個表會被寫入到模組的資料庫，被UDEV以後使用。任何驅動在一開始，都要去註冊，在USB子系統中，driver被usb_register函數使用usb_drivr資料結構來進行註冊。當USB Core認為它已經為一個裝置的interface發現相應的驅動時，probe函數就會被調用。probe函數會完成許多重要的工作，例如：為interface的相關資料分配空間，根據interface的特性，註冊其他kernel子系統（Block，Char，Net，TTY，etc）2.2 通訊大部分情況下，USB裝置的通訊工作在軟體層使用USB Request Blocks（URB）的方式來完成。URB使用非同步方式在endpoint上來發送或接受資料，每個URB被初始化並賦值後會被提交到USB Core，由USB Core來完成後續的工作。使用URB來進行通訊會涉及到許多USB Core API的使用，有時候使用者很希望簡化使用方式，譬如我這種懶人，可愛的kernel開發人員又給我們提供一些介面，我們可以很簡單的完成USB endpoint的通訊工作而不涉及到URB的操作（其實是將URB的操作封裝了）