Linux-USB Gadget : Part 4: 最简单的 gadget驱动：g_zero
Linux-USB Gadget : Part 4:?最簡單的?gadget驅動：g_zero
作者：?zjujoe?轉載請注明出處
Email?：?zjujoe@yahoo.com
BLOG?：?http://blog.csdn.net/zjujoe
前言
前面講過，?gadget api?提供了?usb device controller?驅動和上層?gadget?驅動交互的接口。?UDC?驅動是服務提供者，而各種?gadget?驅動則是服務的使用者。其實還有一些通用代碼，因為功能比較簡單，我們稱之為?helpe?函數。在閱讀了?Gadget API?文檔后，讓我們開始閱讀代碼，?udb?驅動代碼比較復雜，我們先從?gadget?驅動看起。各種?gadget?驅動中，?最簡單的要數?g_zero?驅動。
?
g_zero?驅動簡介
作為最簡單的?gadget?驅動，?g_zero?的功能基于兩個?BULK?端點實現了簡單的輸入輸出功能，?它可以用作寫新的?gadget?驅動的一個實例。?g_zero?驅動還有一個重要角色，?即配合?host?端的?usbtest?（內核模塊及用戶層代碼），?用于測試底層?udc?驅動。當然，也可以是測試主機的控制器驅動。
?
兩個?BULK?端點為一個?IN?端點?,??一個?OUT?端點。基于這兩個（由底層提供的）端點，?g_zero?驅動實現了兩個?configuration?。?第一個?configuration?提供了?sink/source?功能：兩個端點一個負責輸入，一個負責輸出，其中輸出的內容根據設置可以是全?0?，也可以是按照某種算法生成的數據。另一個configuration?提供了?loopback?接口，?IN?端點負責把從?OUT?端點收到的數據反饋給?Host.
?
根據系統配置，?g_zero?驅動提供了全速及高速功能，從而稍微增加了代碼復雜度。另外，它還支持?otg?接口，從?usb2.0?協議我們知道，?otg?其實是?usb device?實現的一個補充功能。它增加了一套接口，使得同一設備可以在設備角色以及有限主機角色之切換。上層?gadget?驅動主要是在描述符方面提供配合支持。下面我們開始看代碼。
模塊初始化
1309?static int?__init?init?(void)
1310?{
1311??????????/* a real value would likely come through some id prom
1312???????????* or module option.??this one takes at least two packets.
1313???????????*/
1314??????????strlcpy?(serial?,?"0123456789.0123456789.0123456789"?, sizeof?serial?);
1315
1316??????????return?usb_gadget_register_driver?(&zero_driver?);
1317?}
1318?module_init?(init?);
1320?static void?__exit?cleanup?(void)
1321?{
1322??????????(&zero_driver?);
1323?}
1324?module_exit?(cleanup?);?usb_gadget_unregister_driver
?
Serial?變量存儲的是設備序列號，我們是一個非正式設備，隨便填充一下。模塊初始化函數調用?usb_gadget_register_driver?來向?udc driver?注冊一個?gadget?驅動， 我們這里是?zero_driver?。而退出函數則會做相反的操作：調用?usb_gadget_unregister_driver?取消原來的注冊。像所有的模塊初始化、退出函數一樣，現在還看不出什么花頭。我們再看一下?zero_driver?的定義：
?
1283?static struct?usb_gadget_driver?zero_driver?= {
1284?#ifdef CONFIG_USB_GADGET_DUALSPEED
1285??????????.speed???????????= USB_SPEED_HIGH,
1286?#else
1287??????????.speed???????????= USB_SPEED_FULL,
1288?#endif
1289??????????.function???????= (char *)?longname?,
1290??????????.bind????????????=?zero_bind?,
1291??????????.unbind?????????=?__exit_p?(zero_unbind?),
1293???????????.setup???????????=?zero_setup?,
1294??????????.disconnect?????=?zero_disconnect?,
1296???????????.suspend????????=?zero_suspend?,
1297??????????.resume?????????=?zero_resume?,
1299??????????.driver??????????= {
1300??????????????????.name????????????= (char *)?shortname?,
1301??????????????????.owner??????????=?THIS_MODULE?,
1302??????????},
1303?};
?
根據?CONFIG_USB_GADGET_DUALSPEED?，代碼選擇是支持高速還是全速，我們使用的?PXA?平臺支持高速傳輸，所以我們假定該配置變量為真。根據?Gadget API?文檔（以及下面的代碼調用圖），在初始化階段?usb_gadget_register_driver?函數會調用?bind?函數，而?setup?函數是用于處理?udc?驅動沒有處理的控制傳輸部分。這兩個函數是整個?zero gadget驅動的精華部分。其它函數則只是為了完整性而提供，有興趣者可以對照?Gadget API?文檔及代碼，自行研究。至于?.driver?成員變量，那主要是為?LDM(linux device module)?服務的。現在關于?LDM?的文檔滿天飛，這里就不多說了。
?
簡單起見，我們目前不去深究?udc?驅動代碼（那比我們的?g_zero?驅動要復雜很多，?而且很多代碼硬件相關，需要閱讀硬件?spec?才能理解），而是使用?kft?及?graphviz?（見參考，?colorant?大俠提供的文檔）工具得到函數調用關系圖：（我們這里使用?pxa udc?驅動，如果使用?dummy_hcd?會得到類似但更簡單的關系圖）
從上圖中，我們可以看到在初始化階段，?udc?驅動會調用?zero?驅動的?bind?函數，也會調用?zero?驅動的?setup?函數?(?主要是得到一些描述符?)?，?setup?函數主要是在后面我們的?device?和主機連接后用于處理控制傳輸的響應（大部分）。在初始階段只是順便幫忙提供點信息，進行的是假傳輸，真提供信息給?udc?驅動。下面我們重點分析?bind?函數。
函數?zero_bind
1140?static int?__init
1141?zero_bind?(struct?usb_gadget?*gadget)
1142?{
1143??????????struct?zero_dev??????????*dev?;
1144??????????struct?usb_ep????????????*ep;
1145??????????int?????????????????????gcnum;
?
首先映入眼簾的是?zero_bind?函數的參數，根據?Gadget API?，一個?gadget?代表一個?usb slave?設備。這個數據結構是在底層控制器驅動中靜態分配的。?Udc?驅動在調用?gadget驅動各接口函數時都會提供這個數據結構。
?
1147??????????/* FIXME this can't yet work right with SH ... it has only
1148???????????* one configuration, numbered one.
1149???????????*/
1150??????????if (gadget_is_sh?(gadget))
1151??????????????????return -ENODEV?;
?
注意我們以前說過?gadget_is_*?系列函數提供了查詢硬件能力的接口，這里用于判斷是否是?SH?平臺的?udc,?如果是，?直接出錯返回：?g_zero?驅動目前還不支持該平臺。
?
1153??????????/* Bulk-only drivers like this one SHOULD be able to
1154???????????* autoconfigure on any sane usb controller driver,
1155???????????* but there may also be important quirks to address.
1156???????????*/
1157??????????usb_ep_autoconfig_reset?(gadget);
?
注意函數?usb_ep_autoconfig_reset?不是由底層?udc?驅動實現，而是我們以前提過的?helper?函數的一部分。該函數功能很簡單：用于清空?gadget?的?端點列表。
?
1158??????????ep =?usb_ep_autoconfig?(gadget, &fs_source_desc?);
1159??????????if (!ep) {
1160?autoconf_fail:
1161???????????????????printk?(KERN_ERR?"%s: can't autoconfigure on %s/n"?,
1162??????????????????????????shortname?, gadget->name?);
1163??????????????????return -ENODEV?;
1164??????????}
1165??????????EP_IN_NAME?= ep->name?;
1166??????????ep->driver_data?= ep;???/* claim */
1167?????????
1168??????????ep =?usb_ep_autoconfig?(gadget, &fs_sink_desc?);
1169??????????if (!ep)
1170??????????????????goto autoconf_fail;
1171??????????EP_OUT_NAME?= ep->name?;
1172??????????ep->driver_data?= ep;???/* claim */
?
函數?usb_ep_autoconfig?根據第二個參數所描述的限制條件，自動尋找適合條件的端點，并插入?gadget?的端點列表。這里?ep?是普通的數據端點，它的?driver_data?不需要存放特殊數據，那就保存一下自己的地址吧。（后面我們將看到?ep0?的?driver_data?放的是?zero_driver?的特殊數據）。我們看一下?fs_source_desc:
?
296?static struct?usb_endpoint_descriptor
297?fs_source_desc?= {
298??????????.bLength =??????????????USB_DT_ENDPOINT_SIZE?,
299??????????.bDescriptorType =??????USB_DT_ENDPOINT?,
300
301??????????.bEndpointAddress =?????USB_DIR_IN?,
302??????????.bmAttributes =?????????USB_ENDPOINT_XFER_BULK?,
303?};
?
可見該描述符描述的是一個類型為?BULK,?方向為?IN?的端點。?fs_sink_desc?的定義類似，描述一個類型為?BULK,?方向為?OUT?的端點。下面繼續看?zero_bind?的代碼。
?
1174??????????gcnum =?usb_gadget_controller_number?(gadget);
1175??????????if (gcnum >= 0)
1176??????????????????device_desc?.bcdDevice?=?cpu_to_le16?(0x0200 + gcnum);
1177??????????else {
1178??????????????????/* gadget zero is so simple (for now, no altsettings) that
1179???????????????????* it SHOULD NOT have problems with bulk-capable hardware.
1180???????????????????* so warn about unrcognized controllers, don't panic.
1181???????????????????*
1182???????????????????* things like configuration and altsetting numbering
1183???????????????????* can need hardware-specific attention though.
1184???????????????????*/
1185??????????????????printk?(KERN_WARNING?"%s: controller '%s' not recognized/n"?,
1186??????????????????????????shortname?, gadget->name?);
1187??????????????????device_desc?.bcdDevice?=?__constant_cpu_to_le16?(0x9999);
1188??????????}
?
每一個?udc?驅動被分配了一個編號，用作該設備描述符里的?bcd?碼。?如果沒有分配，沒辦法，就將就著用?0x9999?吧。
?
1191??????????/* ok, we made sense of the hardware ... */
1192??????????dev?=?kzalloc?(sizeof(*dev?),?GFP_KERNEL?);
1193??????????if (!dev?)
1194??????????????????return -ENOMEM?;
1195??????????spin_lock_init?(&dev?->lock?);
1196??????????dev?->gadget = gadget;
1197??????????set_gadget_data?(gadget,?dev?);
1198
?
stuct gadget?維護所有?gadget?驅動共性的內容，個性的數據則由各?gadget?驅動各自定義，對于?zero,?它定義了?zero_dev.?分配后存放在?gadget?結構的某個角落里：gadget.dev.driver_data?。?zero_dev?定義如下：
?
119?struct?zero_dev?{
120??????????spinlock_t???????????????lock?;
121??????????struct?usb_gadget????????*gadget;
122??????????struct?usb_request???????*req;???????????/* for control responses */
124??????????/* when configured, we have one of two configs:
125???????????* - source data (in to host) and sink it (out from host)
126???????????* - or loop it back (out from host back in to host)
127???????????*/
128??????????u8???????????????????????config?;
129??????????struct?usb_ep????????????*in_ep, *out_ep;
131??????????/* autoresume timer */
132??????????struct?timer_list????????resume;
133?};
?
這里?resume?是用于喚醒?host?的?timer?的列表，?config?表示我們當前使用第幾個?configuration.?其它含義自明。下面繼續看?zero bind?代碼。
?
1199??????????/* preallocate control response and buffer */
1200??????????dev?->req =?usb_ep_alloc_request?(gadget->ep0,?GFP_KERNEL?);
1201??????????if (!dev?->req)
1202??????????????????goto enomem;
1203??????????dev?->req->buf?=?usb_ep_alloc_buffer?(gadget->ep0,?USB_BUFSIZ?,
1204??????????????????????????????????&dev?->req->dma?,?GFP_KERNEL?);
1205??????????if (!dev?->req->buf?)
1206??????????????????goto enomem;
1207
1208??????????dev?->req->complete?=?zero_setup_complete?;
1209
?
這幾行代碼分配用于控制傳輸的請求?/?數據緩沖以及結束函數。控制傳輸是每個?gadget?驅動要使用的傳輸方式，這里及早分配。結束函數?zero_setup_complete?只是打印一下狀態，我們就不貼出了。
?
1210??????????device_desc?.bMaxPacketSize0 = gadget->ep0->maxpacket;
?
這里根據底層的數據初始化設備描述符里端點?0?（控制端點）的最大包大小。
?
1212?#ifdef CONFIG_USB_GADGET_DUALSPEED
1213??????????/* assume ep0 uses the same value for both speeds ... */
1214??????????dev_qualifier?.bMaxPacketSize0 =?device_desc?.bMaxPacketSize0;
1215
1216??????????/* and that all endpoints are dual-speed */
1217??????????hs_source_desc?.bEndpointAddress =?fs_source_desc?.bEndpointAddress;
1218??????????hs_sink_desc?.bEndpointAddress =?fs_sink_desc?.bEndpointAddress;
1219?#endif
?
高速設備需要的額外的描述符，我們對某些字段進行初始化。
?
1221??????????if (gadget->is_otg) {
1222??????????????????otg_descriptor?.bmAttributes |=?USB_OTG_HNP?,
1223??????????????????source_sink_config?.bmAttributes |=?USB_CONFIG_ATT_WAKEUP?;
1224???????????????????loopback_config?.bmAttributes |=?USB_CONFIG_ATT_WAKEUP?;
1225??????????}
?
如果是?otg?設備，則需要在描述符里設置相關特性。
?
1227??????????usb_gadget_set_selfpowered?(gadget);
?
能運行?Linux Gadget?驅動的設備一般電池供電，也就是?selfpowered?。
?
1229???????????init_timer?(&dev?->resume);
1230??????????dev?->resume.function =?zero_autoresume?;
1231??????????dev?->resume.data?= (unsigned long)?dev?;
1232??????????if (autoresume?) {
1233??????????????????source_sink_config?.bmAttributes |=?USB_CONFIG_ATT_WAKEUP?;
1234??????????????????loopback_config?.bmAttributes |=?USB_CONFIG_ATT_WAKEUP?;
1235??????????}
?
這段代碼跟自動喚醒?host?有關，?不深究。
?
1237??????????gadget->ep0->driver_data?=?dev?;
?
多記一份?zero_dev?的地址，?方便使用。
?
1239??????????INFO?(dev?,?"%s, version: "?DRIVER_VERSION?"/n"?,?longname?);
1240??????????INFO?(dev?,?"using %s, OUT %s IN %s/n"?, gadget->name?,
1241???????????????????EP_OUT_NAME?,?EP_IN_NAME?);
1242
1243??????????snprintf?(manufacturer?, sizeof?manufacturer?,?"%s %s with %s"?,
1244??????????????????init_utsname?()->sysname,?init_utsname?()->release?,
1245??????????????????gadget->name?);
1246
1247??????????return 0;
1248
1249?enomem:
1250??????????zero_unbind?(gadget);
1251??????????return -ENOMEM?;
1252?}
?
自此???zero_bind?分析完畢。它主要是為?gadget?驅動找到了合適的端點，并且初始化了設備相關結構?: zero_dev.?從而把?gadget?驅動和???udc?驅動僅僅地綁定在一起。?看到現在，我們還沒有感受到?gadget?驅動的真正意義，?前面的函數就像一座座橋梁，走過這些橋梁，我們終于來到美麗的湖心小島：zero_setup?。
?
函數?zero_setup
zero_setup?完成控制傳輸的大部分功能。比如獲取各種描述符、設置配置等。?Host?首先通過控制傳輸和設備進行通信，告訴設備它底下要干什么。?Zero gadget?驅動比較簡單，在主機進行?set configuration?后，就會在?IN/OUT?端點上準備好數據，供主機去用。并且通過?call?函數，在主機使用完前面準備好的數據后，繼續插入請求，這樣，主機就可以源源不斷的對我們這個設備進行讀寫操作。以下開始看代碼。
?
917?static int
918?zero_setup?(struct?usb_gadget?*gadget, const struct?usb_ctrlrequest?*ctrl?)
919?{
?
照例，我們得到?usb_gadget?結構，同時，我們的第二個參數是?usb_ctrlrequest?結構：
?
140 struct usb_ctrlrequest {
141???????? __u8 bRequestType;
142???????? __u8 bRequest;
143???????? __le16 wValue;
144???????? __le16 wIndex;
145???????? __le16 wLength;
146 } __attribute__ ((packed));
?
具體含義請參考?Usb spec Ch9?。 這里結構名字有點誤導，?usb_ctrlrequest?代表的?是主機傳過來的控制請求。和后面的?usb_request?有較大區別。?usb_request?代表放到端點的隊列里等待主機過來讀寫的一個個數據包。下面我們繼續看?zero_setup?函數代碼。
?
920??????????struct?zero_dev??????????*dev?=?get_gadget_data?(gadget);
921??????????struct?usb_request???????*req =?dev?->req;
922??????????int?????????????????????value?= -EOPNOTSUPP?;
923??????????u16??????????????????????w_index =?le16_to_cpu?(ctrl?->wIndex);
924??????????u16??????????????????????w_value =?le16_to_cpu?(ctrl?->wValue);
925??????????u16??????????????????????w_length =?le16_to_cpu?(ctrl?->wLength);
?
獲得我們在?bind?函數分配的?zero_dev, usb_request?， 以及由主機傳過來的“請求”的各字段。
?
927??????????/* usually this stores reply data in the pre-allocated ep0 buffer,
928???????????* but config change events will reconfigure hardware.*/
930???????????req->zero?= 0;
931??????????switch (ctrl?->bRequest) {
932
933??????????case?USB_REQ_GET_DESCRIPTOR?:
934??????????????????if (ctrl?->bRequestType !=?USB_DIR_IN?)
935???????????????????????????goto?unknown?;
?
請求各種描述符，當然需要是?IN?類型的請求。
?
936??????????????????switch (w_value >> 8) {
938??????????????????case?USB_DT_DEVICE?:
939??????????????????????????value?=?min?(w_length, (u16?) sizeof?device_desc?);
940??????????????????????????memcpy?(req->buf?, &device_desc?,?value?);
941??????????????????????????break;
942?#ifdef CONFIG_USB_GADGET_DUALSPEED
943??????????????????case?USB_DT_DEVICE_QUALIFIER?:
944??????????????????????????if (!gadget->is_dualspeed)
945???????????????????????????????????break;
946??????????????????????????value?=?min?(w_length, (u16?) sizeof?dev_qualifier?);
947??????????????????????????memcpy?(req->buf?, &dev_qualifier?,?value?);
948??????????????????????????break;
?
對應?USB 2.0 Spec CH9,?以上代碼很容易理解。 每一個描述符使用?struct?usb_device_descriptor?描述，比如， 設備描述符：
?
222?static struct?usb_device_descriptor
223?device_desc?= {
224??????????.bLength =??????????????sizeof?device_desc?,
225??????????.bDescriptorType =??????USB_DT_DEVICE?,
226
227??????????.bcdUSB =???????????????__constant_cpu_to_le16?(0x0200),
228??????????.bDeviceClass =?????????USB_CLASS_VENDOR_SPEC?, 0xff
229
230??????????.?idVendor?=?????????????__constant_cpu_to_le16?(?DRIVER_VENDOR_NUM?),
231??????????.?idProduct?=????????????__constant_cpu_to_le16?(?DRIVER_PRODUCT_NUM?),
232??????????.?iManufacturer?=????????STRING_MANUFACTURER?, 25?， 廠商描述符
233??????????.?iProduct?=?????????????STRING_PRODUCT?,????42?，廠品描述符
234???????????.?iSerialNumber?=????????STRING_SERIAL?,?????101,?序列號
235??????????.bNumConfigurations =???2,
236?};
?
950??????????????????case?USB_DT_OTHER_SPEED_CONFIG?:
951??????????????????????????if (!gadget->is_dualspeed)
952??????????????????????????????????break;
953??????????????????????????// FALLTHROUGH
954?#endif?/* CONFIG_USB_GADGET_DUALSPEED */
955??????????????????case?USB_DT_CONFIG?:
956??????????????????????????value?=?config_buf?(gadget, req->buf?,
957??????????????????????????????????????????w_value >> 8,
958??????????????????????????????????????????w_value & 0xff);
959??????????????????????????if (value?>= 0)
960??????????????????????????????????value?=?min?(w_length, (u16?)?value?);
961??????????????????????????break;
?
配置描述符比較復雜，會返回該配置里的接口，端點等信息。配置描述符由：struct?usb_descriptor_header?[]?表達， 而且高速/?全速設備的配置描述符是不一樣。比如，高速loopback?配置的配置描述符為：
?
378?static const struct?usb_descriptor_header?*?hs_loopback_function?[] = {
379??????????(struct?usb_descriptor_header?*) &?otg_descriptor?,
380??????????(struct?usb_descriptor_header?*) &?loopback_intf?,
381??????????(struct?usb_descriptor_header?*) &?hs_source_desc?,
382??????????(struct?usb_descriptor_header?*) &?hs_sink_desc?,
383??????????NULL?,
384?};
?
可見，本質上，配置描述符是返回一組描述符。下面看一下配置描述符是如何生成的。
?
432?static int
433?config_buf?(struct?usb_gadget?*gadget,
434???????????????????u8?*?buf?,?u8?type?, unsigned?index?)
435?{
436??????????int?????????????????????????????is_source_sink;
437??????????int??????????????????????????????len?;
438??????????const struct?usb_descriptor_header?**function;
439?#ifdef CONFIG_USB_GADGET_DUALSPEED
440??????????int?????????????????????????????hs = (gadget->?speed?== USB_SPEED_HIGH);
441?#endif
442
443??????????/* two configurations will always be index 0 and index 1 */
444??????????if (?index?> 1)
445??????????????????return -?EINVAL?;
446??????????is_source_sink =?loopdefault?? (?index?== 1) : (?index?== 0);
447
448?#ifdef CONFIG_USB_GADGET_DUALSPEED
449??????????if (?type?==?USB_DT_OTHER_SPEED_CONFIG?)
450??????????????????hs = !hs;
451??????????if (hs)
452??????????????????function = is_source_sink
453????????????????????????????hs_source_sink_function
454??????????????????????????:?hs_loopback_function?;
455??????????else
456?#endif
457??????????????????function = is_source_sink
458????????????????????????????fs_source_sink_function
459??????????????????????????:?fs_loopback_function?;
460
461??????????/* for now, don't advertise srp-only devices */
462??????????if (!gadget->is_otg)
463??????????????????function++;
464
465??????????len?=?usb_gadget_config_buf?(is_source_sink
466??????????????????????????????????????????? &?source_sink_config
467??????????????????????????????????????????: &?loopback_config?,
468??????????????????????????buf?,?USB_BUFSIZ?, function);
469??????????if (?len?< 0)
470???????????????????return?len?;
471??????????((struct?usb_config_descriptor?*)?buf?)->bDescriptorType =?type?;
472??????????return?len?;
473?}
?
代碼很簡單，?config_buf?函數根據當前是否是高速設備，以及是否是?otg?設備，選擇合適的?configuration( souce sink config or loopback config)?，?調用usb_gadget_config_buf?生成最終的配置描述符。可以想象?usb_gadget_config_buf?的實現非常簡單?:?根據傳過來的?描述符列表?(?以?NULL?指針結束?)?，使用?memcpy??之類見每個描述符的內容拷貝到?buf?里。?下面我們繼續看???zero_setup?函數。
?
963??????????????????case?USB_DT_STRING?:
964??????????????????????????/* wIndex == language code.
965???????????????????????????* this driver only handles one language, you can
966???????????????????????????* add string tables for other languages, using
967???????????????????????????* any UTF-8 characters
968???????????????????????????*/
969??????????????????????????value?=?usb_gadget_get_string?(&stringtab?,
970??????????????????????????????????????????w_value & 0xff, req->buf?);
971??????????????????????????if (value?>= 0)
972??????????????????????????????????value?=?min?(w_length, (u16?)?value?);
973??????????????????????????break;
974??????????????????}
975??????????????????break;
976
?
根據?host?傳遞過來的索引，響應相應的字符串。Zero?驅動的字符串描述符則只支持一種語言（0409, en-us?）：
?
409?static struct?usb_gadget_strings?????????stringtab?= {
410??????????.language???????= 0x0409,???????/* en-us */
411??????????.strings?????????=?strings?,
412?};
?
399?/* static strings, in UTF-8 */
400?static struct?usb_string?????????????????strings?[] = {
401??????????{?STRING_MANUFACTURER?,?manufacturer?, },
402??????????{?STRING_PRODUCT?,?longname?, },
403??????????{?STRING_SERIAL?,?serial?, },
404??????????{?STRING_LOOPBACK?,?loopback?, },
405??????????{?STRING_SOURCE_SINK?,?source_sink?, },
406??????????{??}????????????????????/* end of list */
407?};
?
有點像應用層（比如?vc?）為了支持多語言而獨立出來的字符串資源。事實上就是這樣！我們可以很容易再增加一種語言。下面我們繼續看???zero_setup?函數。
?
977??????????/* currently two configs, two speeds */
978??????????case?USB_REQ_SET_CONFIGURATION?:
979??????????????????if (ctrl?->bRequestType != 0)
980??????????????????????????goto?unknown?;
981??????????????????if (gadget->a_hnp_support)
982??????????????????????????DBG?(dev?,?"HNP available/n"?);
983??????????????????else if (gadget->a_alt_hnp_support)
984??????????????????????????DBG?(dev?,?"HNP needs a different root port/n"?);
985??????????????????else
986??????????????????????????VDBG?(dev?,?"HNP inactive/n"?);
987??????????????????spin_lock?(&dev?->lock?);
988??????????????????value?=?zero_set_config?(dev?, w_value,?GFP_ATOMIC?);
989??????????????????spin_unlock?(&dev?->lock?);
990??????????????????break;
?
設置設備的當前配置，到這里，才凌空一腳，將設備帶入數據傳輸狀態，我們先把zero_setup?看完，再仔細看函數?zero_set_config?。
?
991??????????case?USB_REQ_GET_CONFIGURATION?:
992??????????????????if (ctrl?->bRequestType !=?USB_DIR_IN?)
993??????????????????????????goto?unknown?;
994??????????????????*(u8?*)req->buf?=?dev?->config?;
995??????????????????value?=?min?(w_length, (u16?) 1);
996??????????????????break;
?
獲取設備的當前配置
?
998??????????/* until we add altsetting support, or other interfaces,
999???????????* only 0/0 are possible.??pxa2xx only supports 0/0 (poorly)
1000???????????* and already killed pending endpoint I/O.
1001???????????*/
1002??????????case?USB_REQ_SET_INTERFACE?:
1003??????????????????if (ctrl?->bRequestType !=?USB_RECIP_INTERFACE?)
1004???????????????????????????goto?unknown?;
1005??????????????????spin_lock?(&dev?->lock?);
1006??????????????????if (dev?->config?&& w_index == 0 && w_value == 0) {
1007??????????????????????????u8???????????????config?=?dev?->config?;
1008
1009??????????????????????????/* resets interface configuration, forgets about
1010???????????????????????????* previous transaction state (queued bufs, etc)
1011???????????????????????????* and re-inits endpoint state (toggle etc)
1012???????????????????????????* no response queued, just zero status == success.
1013???????????????????????????* if we had more than one interface we couldn't
1014????????????????????????????* use this "reset the config" shortcut.
1015???????????????????????????*/
1016??????????????????????????zero_reset_config?(dev?);
1017??????????????????????????zero_set_config?(dev?,?config?,?GFP_ATOMIC?);
1018??????????????????????????value?= 0;
1019??????????????????}
1020??????????????????spin_unlock?(&dev?->lock?);
1021??????????????????break;
?
設置接口，由于我們每個configuration?只有一個接口，所以這里的效果跟前面設置配置類似。
由于?zero_set_config?函數會調用?zero_reset_config,?所以這里應該可以不調用?zero_reset_config.
?
1022??????????case?USB_REQ_GET_INTERFACE?:
1023??????????????????if (ctrl?->bRequestType != (USB_DIR_IN?|USB_RECIP_INTERFACE?))
1024??????????????????????????goto?unknown?;
1025??????????????????if (!dev?->config?)
1026??????????????????????????break;
1027??????????????????if (w_index != 0) {
1028??????????????????????????value?= -EDOM?;
1029??????????????????????????break;
1030???????????????????}
1031??????????????????*(u8?*)req->buf?= 0;
1032??????????????????value?=?min?(w_length, (u16?) 1);
1033??????????????????break;
1034
?
獲取設備的當前配置的當前接口。
?
1035??????????/*
1036???????????* These are the same vendor-specific requests supported by
1037????????????* Intel's USB 2.0 compliance test devices.??We exceed that
1038???????????* device spec by allowing multiple-packet requests.
1039???????????*/
1040??????????case 0x5b:???????/* control WRITE test -- fill the buffer */
1041??????????????????if (ctrl?->bRequestType != (USB_DIR_OUT?|USB_TYPE_VENDOR?))
1042???????????????????????????goto?unknown?;
1043??????????????????if (w_value || w_index)
1044??????????????????????????break;
1045??????????????????/* just read that many bytes into the buffer */
1046??????????????????if (w_length >?USB_BUFSIZ?)
1047??????????????????????????break;
1048???????????????????value?= w_length;
1049??????????????????break;
1050??????????case 0x5c:???????/* control READ test -- return the buffer */
1051???????????????????if (ctrl?->bRequestType != (USB_DIR_IN?|USB_TYPE_VENDOR?))
1052??????????????????????????goto?unknown?;
1053??????????????????if (w_value || w_index)
1054??????????????????????????break;
1055??????????????????/* expect those bytes are still in the buffer; send back */
1056??????????????????if (w_length >?USB_BUFSIZ
1057???????????????????????????????????|| w_length != req->length?)
1058??????????????????????????break;
1059??????????????????value?= w_length;
1060??????????????????break;
1061
?
根據協議，我們可以定制私有的類型，這里是?Intel?定義的測試類型，用于測試端點0?的數據收發。端點0?通常用于控制傳輸， 用它進行數據傳輸完全是為了測試目的。
?
1062??????????default:
1063?unknown?:
1064??????????????????VDBG?(dev?,
1065??????????????????????????"unknown control req%02x.%02x v%04x i%04x l%d/n"?,
1066??????????????????????????ctrl?->bRequestType,?ctrl?->bRequest,
1067??????????????????????????w_value, w_index, w_length);
1068??????????}
1069
1070??????????/* respond with data transfer before status phase? */
1071??????????if (value?>= 0) {
1072??????????????????req->length?=?value?;
1073??????????????????req->zero?=?value?< w_length;
1074??????????????????value?=?usb_ep_queue?(gadget->ep0, req,?GFP_ATOMIC?);
1075??????????????????if (value?< 0) {
1076???????????????????????????DBG?(dev?,?"ep_queue --> %d/n"?,?value?);
1077??????????????????????????req->status?= 0;
1078??????????????????????????zero_setup_complete?(gadget->ep0, req);
1079??????????????????}
1080??????????}
?
如果有數據需要傳給?Host,?則將其放到端點0?的傳送隊列。底層?udc?驅動會負責將其發給?host.
?
1082??????????/* device either stalls (value < 0) or reports success */
1083??????????return?value?;
1084?}
?
函數?zero_setup?完成了?usb spec ch9?定義的很多功能。而我們前面介紹的?bulk-in/bulk-out?數據端點開始工作則是在?set configuration?（或者?set interface?）后，由?zero_set_config?函數觸發。下面開始分析該函數。
?
函數zero_set_config
848?static int
849?zero_set_config?(struct?zero_dev?*dev?, unsigned?number?,?gfp_t?gfp_flags)
850?{
851??????????int?????????????????????result?= 0;
852??????????struct?usb_gadget????????*gadget =?dev?->gadget;
853
854???????????if (number?==?dev?->config?)
855??????????????????return 0;
862??????????zero_reset_config?(dev?);
863
?
函數?zero_reset_config?把所有的?端點置于?disable?狀態。
?
864??????????switch (number?) {
865??????????case?CONFIG_SOURCE_SINK?:
866??????????????????result?=?set_source_sink_config?(dev?, gfp_flags);
867??????????????????break;
868??????????case?CONFIG_LOOPBACK?:
869???????????????????result?=?set_loopback_config?(dev?, gfp_flags);
870??????????????????break;
871???????????default:
872??????????????????result?= -EINVAL?;
873??????????????????/* FALL THROUGH */
874??????????case 0:
875??????????????????return?result?;
876??????????}
?
根據當前的配置，設置兩種不同的傳送方式。我們假定?host?設置的是?loopback?方式。另一種方式是類似的?(?數據內容不同?)?。
?
878??????????if (!result?&& (!dev?->in_ep || !dev?->out_ep))
879??????????????????result?= -ENODEV?;
880??????????if (result?)
881??????????????????zero_reset_config?(dev?);
882??????????else {
883??????????????????char *speed?;
884
885??????????????????switch (gadget->speed?) {
886??????????????????case USB_SPEED_LOW:?????speed?=?"low"?; break;
887??????????????????case USB_SPEED_FULL:????speed?=?"full"?; break;
888??????????????????case USB_SPEED_HIGH:????speed?=?"high"?; break;
889??????????????????default:????????????????speed?=?"?"?; break;
890??????????????????}
891
892??????????????????dev?->config?=?number?;
893??????????????????INFO?(dev?,?"%s speed config #%d: %s/n"?,?speed?,?number?,
894??????????????????????????????????(number?==?CONFIG_SOURCE_SINK?)
895????????????????????????????????????????????source_sink?:?loopback?);
896??????????}
897??????????return?result?;
898?}
一些善后處理。?下面我們看函數?set_loopback_config
函數?set_loopback_config
747?static int
748?set_loopback_config?(struct?zero_dev?*dev?,?gfp_t?gfp_flags)
749?{
750??????????int?????????????????????result?= 0;
751??????????struct?usb_ep????????????*ep;
752??????????struct?usb_gadget????????*gadget =?dev?->gadget;
753
754??????????gadget_for_each_ep?(ep, gadget) {
?
針對?gadget?端點列表的每一個端點進行操作。
?
755??????????????????const struct?usb_endpoint_descriptor?????*d;
756
757??????????????????/* one endpoint writes data back IN to the host */
758??????????????????if (strcmp?(ep->name?,?EP_IN_NAME?) == 0) {
759??????????????????????????d =?ep_desc?(gadget, &hs_source_desc?, &fs_source_desc?);
760??????????????????????????result?=?usb_ep_enable?(ep, d);
761??????????????????????????if (result?== 0) {
762???????????????????????????????????ep->driver_data?=?dev?;
763??????????????????????????????????dev?->in_ep = ep;
764???????????????????????????????????continue;
765??????????????????????????}
766
767??????????????????/* one endpoint just reads OUT packets */
768??????????????????} else if (strcmp?(ep->name?,?EP_OUT_NAME?) == 0) {
769??????????????????????????d =?ep_desc?(gadget, &hs_sink_desc?, &fs_sink_desc?);
770??????????????????????????result?=?usb_ep_enable?(ep, d);
771??????????????????????????if (result?== 0) {
772??????????????????????????????????ep->driver_data?=?dev?;
773??????????????????????????????????dev?->out_ep = ep;
774??????????????????????????????????continue;
775??????????????????????????}
776
777??????????????????/* ignore any other endpoints */
778??????????????????} else
779??????????????????????????continue;
780
781??????????????????/* stop on error */
782??????????????????ERROR?(dev?,?"can't enable %s, result %d/n"?, ep->name?,?result?);
783??????????????????break;
784??????????}
?
激活端點。并設置速度?(?高速或者全速?)?。
?
786??????????/* allocate a bunch of read buffers and queue them all at once.
787???????????* we buffer at most 'qlen' transfers; fewer if any need more
788???????????* than 'buflen' bytes each.
789???????????*/
790??????????if (result?== 0) {
791??????????????????struct?usb_request???????*req;
792??????????????????unsigned????????????????i?;
793
794??????????????????ep =?dev?->out_ep;
795??????????????????for (i?= 0;?i?<?qlen?&&?result?== 0;?i?++) {
796??????????????????????????req =?alloc_ep_req?(ep,?buflen?);
797??????????????????????????if (req) {
798??????????????????????????????????req->complete?=?loopback_complete?;
799??????????????????????????????????result?=?usb_ep_queue?(ep, req,?GFP_ATOMIC?);
800??????????????????????????????????if (result?)
801??????????????????????????????????????????DBG?(dev?,?"%s queue req --> %d/n"?,
802??????????????????????????????????????????????????????????ep->name?,?result?);
803??????????????????????????} else
804??????????????????????????????????result?= -ENOMEM?;
805??????????????????}
806??????????}
?
首先在?OUT?端點上掛一堆請求（?usb_request?）?,?等待主機向我們發送數據。等主機真正對我們進行?OUT?數據傳輸并且數據傳完后，會調用?loopback_complete?回調函數。
?
807??????????if (result?== 0)
808??????????????????DBG?(dev?,?"qlen %d, buflen %d/n"?,?qlen?,?buflen?);
809
810???????????/* caller is responsible for cleanup on error */
811??????????return?result?;
812?}
?
下面看?函數?loopback_complete
?
函數?loopback_complete
698?static void?loopback_complete?(struct?usb_ep?*ep, struct?usb_request?*req)
699?{
700??????????struct?zero_dev?*dev?= ep->driver_data?;
701???????????int?????????????status?= req->status?;
702
703??????????switch (status?) {
704
705??????????case 0:?????????????????????????/* normal completion? */
706??????????????????if (ep ==?dev?->out_ep) {
707??????????????????????????/* loop this OUT packet back IN to the host */
708??????????????????????????req->zero?= (req->actual < req->length?);
709??????????????????????????req->length?= req->actual;
710??????????????????????????status?=?usb_ep_queue?(dev?->in_ep?, req,?GFP_ATOMIC?);
711??????????????????????????if (status?== 0)
712??????????????????????????????????return;
713
714??????????????????????????/* "should never get here" */
715??????????????????????????ERROR?(dev?,?"can't loop %s to %s: %d/n"?,
716??????????????????????????????????ep->name?,?dev?->in_ep->name?,
717??????????????????????????????????status?);
718??????????????????}
719
720??????????????????/* queue the buffer for some later OUT packet */
721??????????????????req->length?=?buflen?;
722??????????????????status?=?usb_ep_queue?(dev?->out_ep?, req,?GFP_ATOMIC?);
723???????????????????if (status?== 0)
724??????????????????????????return;
725
726??????????????????/* "should never get here" */
727??????????????????/* FALLTHROUGH */
728
729??????????default:
730??????????????????ERROR?(dev?,?"%s loop complete --> %d, %d/%d/n"?, ep->name?,
731??????????????????????????????????status?, req->actual, req->length?);
732??????????????????/* FALLTHROUGH */
733
734??????????/* NOTE:??since this driver doesn't maintain an explicit record
735????????????* of requests it submitted (just maintains qlen count), we
736???????????* rely on the hardware driver to clean up on disconnect or
737???????????* endpoint disable.
738???????????*/
739??????????case -ECONNABORTED?:?????????????/* hardware forced ep reset */
740??????????case -ECONNRESET?:???????????????/* request dequeued */
741??????????case -ESHUTDOWN?:????????????????/* disconnect from host */
742??????????????????free_ep_req?(ep, req);
743???????????????????return;
744??????????}
745?}
?
如果?OUT?傳輸正常結束，則會將其放到?IN?端點的傳輸隊列。
如果?IN?傳輸正常結束，則會將其放到?OUT?端點的傳輸隊列。
這樣，通過回調函數不斷在兩個隊列?(IN/OUT)?之間切換這些請求?(usb_request),?就實現了在主機看來的?loopback?設備。
總結
Gadget?驅動的特殊性在于它是?host?端對等驅動的?slave,?而不是上層某個應用的?slave.?響應的，它是實現是很有意思的。我們沒有看到?read/write?函數，也沒有看到我們最常實現的?ioctl?函數，?而是把重點放在回調函數?zero_setup?上。?g_zero gadget?驅動實現了一個最簡單的?bulk-in/bulk-out?功能，向我們展示了?gadget?驅動如果利用?gadget API?來完成數據傳輸功能。對于復雜的?gadget?驅動，?setup?回調函數只是一個起點。
?
參考
USB 2.0 Spec
http://www.usb.org/developers/docs/
?
用?KFI?和?Graphviz?跟蹤?/?優化內核代碼
http://blog.csdn.net/colorant/archive/2008/07/09/2627493.aspx
總結
以上是生活随笔為你收集整理的Linux-USB Gadget : Part 4: 最简单的 gadget驱动：g_zero的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： CF372D. Choosing Sub
- 下一篇： 注册AppStore开发者账号以及收款设