wifi詳解（四）

時間 2019-11-17

標籤 wifi 詳解欄目無線简体版

原文原文鏈接

1 IOCTL的調用邏輯

之因此要分析這個，是由於上層wpa_supplicant和WIFI驅動打交道的方式，多半是經過ioctl的方式進行的，因此看看它的調用邏輯（這裏只列出其主要的調用邏輯）： linux

上面即是用戶ioctl調用的流程圖，它最終分爲兩條線即有兩種支持，選擇那一條或兩條都選（我的感受最好選第2條線，由於它最後也是會調用到相應的函數的，並且還有其它更多的命令支持），從實際的代碼來看，若是dev->netdev_ops android

->ndo_do_ioctl被初始化了，那麼它必定會被調用，是否被初始化，在前面選擇對net結構變量的初始化方式中有討論過。緩存

下面來具體看看該調用流程，首先說明下，上面的流程主要實如今kernel/net/wireless/wext_core.c文件中，這是 wireless的協議層實現，剛好咱們在wpa_supplicant中一般選擇的驅動類型也是wext，它的入口函數是 wext_ioctl_dispatch：服務器

/* entry point from dev ioctl*/ 網絡

static int wext_ioctl_dispatch(struct net *net, struct ifreq*ifr, app

unsigned int cmd, struct iw_request_info *info, 框架

wext_ioctl_func standard, less

wext_ioctl_funcprivate) socket

{ ide

int ret = wext_permission_check(cmd);

if (ret)

return ret;

dev_load(net, ifr->ifr_name);

rtnl_lock();

ret = wireless_process_ioctl(net, ifr, cmd, info, standard,private);

rtnl_unlock();

return ret;

}

它其實就是wireless_process_ioctl的封裝函數，除了進行許可權限的確認，沒有作什麼其它內容，這裏有standard和 private兩個函數指針的傳遞，其實就是兩個回調函數，在後面會用到，它是由wext_handle_ioctl函數傳遞過來的：

int wext_handle_ioctl(structnet *net, struct ifreq *ifr, unsigned int cmd,

void __user *arg)

{

struct iw_request_info info = { .cmd =cmd, .flags = 0 };

int ret;

ret = wext_ioctl_dispatch(net, ifr, cmd, &info,

ioctl_standard_call,

ioctl_private_call); //這兩個回調函數的定義以後再討論，這裏暫不理論

if (ret >= 0 &&

IW_IS_GET(cmd) &&

copy_to_user(arg, ifr, sizeof(structiwreq)))

return -EFAULT;

return ret;

}

實際上傳遞的就是ioctl_standard_call和ioctl_private_call兩個函數，在看看wireless_process_ioctl函數，這個函數很重要，下面作重點分析：

static intwireless_process_ioctl(struct net *net, struct ifreq *ifr,

unsigned int cmd,

structiw_request_info *info,

wext_ioctl_func standard,

wext_ioctl_func private)

{

struct iwreq *iwr = (struct iwreq *)ifr;

struct net_device *dev;

iw_handler handler;

/* Permissions are already checked indev_ioctl() before calling us.

* The copy_to/from_user() of ifr isalso dealt with in there */

/* Make sure the device exist */

if ((dev = __dev_get_by_name(net, ifr->ifr_name)) == NULL) //經過網絡接口名獲取net_device設備

return -ENODEV;

/* A bunch of special cases, then thegeneric case...

* Note that 'cmd' is already filteredin dev_ioctl() with

* (cmd >= SIOCIWFIRST &&cmd <= SIOCIWLAST) */

if (cmd == SIOCGIWSTATS)

returnstandard(dev, iwr, cmd, info,

&iw_handler_get_iwstats); //若是是狀態查詢命令，調用該函數（回調函數中的一個）

#ifdef CONFIG_WEXT_PRIV

if (cmd == SIOCGIWPRIV && dev->wireless_handlers)

returnstandard(dev, iwr, cmd, info,

iw_handler_get_private); //若是是專有命令，調用回調函數，同上

#endif

/* Basic check */

if (!netif_device_present(dev))

return -ENODEV;

/* New driver API : try to find thehandler */

handler = get_handler(dev, cmd); //根據cmd參數，從dev成員中查詢相應的處理函數

if (handler) {

/* Standard and private are notthe same */

if (cmd < SIOCIWFIRSTPRIV)

return standard(dev, iwr, cmd, info, handler); //調用相應命令的處理函數

else if (private)

return private(dev, iwr, cmd, info, handler); //同上

}

/* Old driver API : call driver ioctlhandler */

if(dev->netdev_ops->ndo_do_ioctl)

return dev->netdev_ops->ndo_do_ioctl(dev,ifr, cmd); //若是被設置就調用該函數

return -EOPNOTSUPP;

}

該函數的大意是，經過網絡接口名稱得到一個網絡設備，而後根據命令的類型調用相應的處理函數，特別的是當 dev->netdev_ops->ndo_do_ioctl或dev->wireless_handlers被設置時，則會查找執行對應的處理函數。Get_handle函數用於查詢處理函數使用：

static iw_handlerget_handler(struct net_device *dev, unsigned int cmd)

{

/* Don't "optimise" thefollowing variable, it will crash */

unsigned int index; /* *MUST* be unsigned */

const struct iw_handler_def *handlers = NULL;

#ifdef CONFIG_CFG80211_WEXT

if (dev->ieee80211_ptr &&dev->ieee80211_ptr->wiphy)

handlers =dev->ieee80211_ptr->wiphy->wext; //初始化默認的處理函數

#endif

#ifdef CONFIG_WIRELESS_EXT

if (dev->wireless_handlers)

handlers= dev->wireless_handlers; //這裏的dev->wireless_handlers在net初始化時被做爲擴張功能選擇性的設置，前面有提到過

#endif

if (!handlers)

return NULL;

/* Try as a standard command */

index = IW_IOCTL_IDX(cmd);

if (index <handlers->num_standard)

returnhandlers->standard[index]; //返回對應的標準函數

#ifdef CONFIG_WEXT_PRIV

/* Try as a private command */

index = cmd - SIOCIWFIRSTPRIV;

if (index <handlers->num_private)

return handlers->private[index]; //返回對應的專有函數

#endif

/* Not found */

return NULL;

}

那麼這個dev->wireless_handlers到底是什麼，這裏來揭開它的神祕面紗，在bcm4329源碼src/wl/sys/wl_iw.c中，有它的定義：

static const iw_handler wl_iw_handler[]=

{

(iw_handler) wl_iw_config_commit,

(iw_handler) wl_iw_get_name,

(iw_handler) NULL,

......

}

static const iw_handler wl_iw_priv_handler[]= {

NULL,

(iw_handler)wl_iw_set_active_scan,

NULL,

(iw_handler)wl_iw_get_rssi,

......

}

const struct iw_handler_def wl_iw_handler_def =

{

.num_standard =ARRAYSIZE(wl_iw_handler),

.standard = (iw_handler *) wl_iw_handler,

.num_private = ARRAYSIZE(wl_iw_priv_handler),

.num_private_args =ARRAY_SIZE(wl_iw_priv_args),

.private = (iw_handler *)wl_iw_priv_handler,

.private_args = (void *)wl_iw_priv_args,

#if WIRELESS_EXT >= 19

get_wireless_stats:dhd_get_wireless_stats,

#endif

};

#endif

在net初始化的時候，這裏把dev->wireless_handlers和dev->netdev_ops的初始化代碼再貼出來：

int

dhd_net_attach(dhd_pub_t*dhdp, int ifidx)

{

……

#if (LINUX_VERSION_CODE <KERNEL_VERSION(2, 6, 31))

ASSERT(!net->open);

net->get_stats = dhd_get_stats;

net->do_ioctl =dhd_ioctl_entry;

net->hard_start_xmit = dhd_start_xmit;

net->set_mac_address = dhd_set_mac_address;

net->set_multicast_list = dhd_set_multicast_list;

net->open =net->stop = NULL;

#else

ASSERT(!net->netdev_ops);

net->netdev_ops = &dhd_ops_virt;

#endif

……

#if WIRELESS_EXT > 12

net->wireless_handlers = (struct iw_handler_def*)&wl_iw_handler_def; //這裏的初始化工做很重要，以後的ioctl流程會涉及到對它的使用

#endif /* WIRELESS_EXT > 12*/

……

}

看到這裏，應該能夠明白相應的命令最終會在wl_iw.c中被執行，這些處理函數也是在該文件中實現。上面已經獲取了命令的處理函數，那麼它是如何被執行的呢？這裏wireless_process_ioctl裏有standard和private的回調函數的調用：

static intioctl_standard_call(struct net_device * dev,

structiwreq *iwr,

unsigned int cmd,

structiw_request_info *info,

iw_handler handler)

{

const struct iw_ioctl_description* descr;

int ret = -EINVAL;

/* Get the description of the IOCTL */

if (IW_IOCTL_IDX(cmd) >=standard_ioctl_num)

return -EOPNOTSUPP;

descr =&(standard_ioctl[IW_IOCTL_IDX(cmd)]);

/* Check if we have a pointer to userspace data or not */

if (descr->header_type !=IW_HEADER_TYPE_POINT) {

/* No extra arguments. Trivialto handle */

ret = handler(dev, info, &(iwr->u),NULL);

/* Generate an event to notifylisteners of the change */

if ((descr->flags &IW_DESCR_FLAG_EVENT) &&

((ret == 0) || (ret ==-EIWCOMMIT)))

wireless_send_event(dev, cmd, &(iwr->u),NULL);

} else {

ret =ioctl_standard_iw_point(&iwr->u.data, cmd, descr,

handler, dev, info);

}

/* Call commit handler if needed anddefined */

if (ret == -EIWCOMMIT)

ret =call_commit_handler(dev);

/* Here, we will generate theappropriate event if needed */

return ret;

}

回調函數中對傳遞過來的handler函數指針進行呼叫，對應的處理函數就會被執行，固然用戶傳送的命令還不止這些，因此纔會有net->netdev_ops的存在的必要性。下面來就來看看執行到：

return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd); //wireless_process_ioctl的最後一句

就會調用dhd_ioctl函數，這是wlan驅動對ioctl調用的處理函數，就是根據用戶傳遞過來的cmd，給它找一個最合適最合理的「歸宿」。

static int

dhd_ioctl_entry(structnet_device *net, struct ifreq *ifr, int cmd)

{

......#ifdefined(CONFIG_WIRELESS_EXT)

/* linux wireless extensions */

if ((cmd >= SIOCIWFIRST) &&(cmd <= SIOCIWLAST)) {

/* may recurse, do NOT lock */

ret = wl_iw_ioctl(net, ifr, cmd);

DHD_OS_WAKE_UNLOCK(&dhd->pub);

return ret;

}

#endif /*defined(CONFIG_WIRELESS_EXT) */

#if LINUX_VERSION_CODE >KERNEL_VERSION(2, 4, 2)

if (cmd == SIOCETHTOOL) {

ret = dhd_ethtool(dhd,(void*)ifr->ifr_data);

DHD_OS_WAKE_UNLOCK(&dhd->pub);

return ret;

}

#endif /* LINUX_VERSION_CODE> KERNEL_VERSION(2, 4, 2) */

if (cmd == SIOCDEVPRIVATE+1) {

ret = wl_android_priv_cmd(net, ifr, cmd);

dhd_check_hang(net,&dhd->pub, ret);

DHD_OS_WAKE_UNLOCK(&dhd->pub);

return ret;

}

if (cmd != SIOCDEVPRIVATE) {

DHD_OS_WAKE_UNLOCK(&dhd->pub);

return -EOPNOTSUPP;

}

memset(&ioc, 0, sizeof(ioc));

......

bcmerror = dhd_wl_ioctl(&dhd->pub, ifidx, (wl_ioctl_t*)&ioc, buf, buflen);

......

}

限於篇幅，該函數處理過程再也不詳述，大體的命令處理方法類似，wl_iw.c中的系列處理函數只是其中的一部分，wl_android中和dhd_linux.c也有相應的處理函數。

2 數據的傳送

2.1 數據傳送過程簡述

傳送指的是經過一個網絡鏈接發送一個報文的行爲.。不管什麼時候內核須要傳送一個數據報文, 它都必須調用驅動的 hard_start_xmit 方法將數據放在外出隊列上。

每一個內核處理的報文都包含在一個 socket緩存結構( 結構 sk_buff )裏, 定義見<linux/skbuff.h>。這個結構從 Unix 抽象中得名, 用來表明一個網絡鏈接socket.。對於接口來講, 一個 socket 緩存只是一個報文。

傳給 hard_start_xmit 的socket 緩存包含物理報文, 它應當出如今媒介上, 以傳輸層的頭部結束。接口不須要修改要傳送的數據.。skb->data指向要傳送的報文，skb->len 是以字節計的長度。傳送下來的sk_buff中的數據已經包含硬件須要的幀頭（這是經過hard_header函數將傳遞進入的信息，組織成設備特有的硬件頭），因此在發送方法裏不須要再填充硬件幀頭，數據能夠直接提交給硬件發送。sk_buff是被鎖住的(locked)，確保其餘程序不會存取它。

全部的網絡設備驅動程序都必須有這個發送方法。在系統調用驅動程序的xmit時，發送的數據放在一個sk_buff 結構中。通常的驅動程序把數據傳給硬件發出去。也有一些特殊的設備好比loopback把數據組成一個接收數據再回送給系統，或者dummy設備直接丟棄數據。若是發送成功，hard_start_xmit方法裏釋放sk_buff，返回0(發送成功)。

2.2 Bcm4329芯片wlan驅動數據傳送

當上層傳送過來報文，調用hard_start_xmit函數（該方法主用於初始化數據包的傳輸），該函數主要用於轉換 sk_buf，將其組織成pktbuf數據格式，而後調用dhd_sendpkt函數將pktbuf經過dhd bus發送到wifi芯片，最後硬件wifi芯片將報文radio發送到網絡上。

int

dhd_start_xmit(struct sk_buff *skb,struct net_device *net)

{

......

/* Convert to packet */

if (!(pktbuf =PKTFRMNATIVE(dhd->pub.osh, skb))) {

DHD_ERROR(("%s:PKTFRMNATIVE failed\n",

dhd_ifname(&dhd->pub, ifidx)));

dev_kfree_skb_any(skb); //轉換成功，釋放skb，在一般處理中，會在中斷中作該操做

ret = -ENOMEM;

goto done;

}

#ifdef WLMEDIA_HTSF

if (htsfdlystat_sz &&PKTLEN(dhd->pub.osh, pktbuf) >= ETHER_ADDR_LEN) {

uint8 *pktdata = (uint8*)PKTDATA(dhd->pub.osh, pktbuf);

struct ether_header *eh =(struct ether_header *)pktdata;

if(!ETHER_ISMULTI(eh->ether_dhost) &&

(ntoh16(eh->ether_type) == ETHER_TYPE_IP)) {

eh->ether_type =hton16(ETHER_TYPE_BRCM_PKTDLYSTATS);

}

#endif

ret = dhd_sendpkt(&dhd->pub, ifidx,pktbuf); //發送pktbuf

......

}

int

dhd_sendpkt(dhd_pub_t *dhdp, intifidx, void *pktbuf)

{

......

#ifdef PROP_TXSTATUS

if (dhdp->wlfc_state &&((athost_wl_status_info_t*)dhdp->wlfc_state)->proptxstatus_mode

!= WLFC_FCMODE_NONE) {

dhd_os_wlfc_block(dhdp);

ret =dhd_wlfc_enque_sendq(dhdp->wlfc_state, DHD_PKTTAG_FIFO(PKTTAG(pktbuf)),

pktbuf);

dhd_wlfc_commit_packets(dhdp->wlfc_state, (f_commitpkt_t)dhd_bus_txdata,

dhdp->bus);

if(((athost_wl_status_info_t*)dhdp->wlfc_state)->toggle_host_if) {

((athost_wl_status_info_t*)dhdp->wlfc_state)->toggle_host_if= 0;

}

dhd_os_wlfc_unblock(dhdp);

}

else

/* non-proptxstatus way */

ret = dhd_bus_txdata(dhdp->bus, pktbuf); //在SDIO總線上傳輸

#else

ret = dhd_bus_txdata(dhdp->bus, pktbuf);

#endif /* PROP_TXST

......

}

傳輸結束後，會產生一箇中斷，即傳輸結束中斷，通常的網絡驅動程序都會有這個中斷的註冊，但還有一種輪詢方式，這在後面的數據的接收部分會有介紹，而sk_buf就在這個中斷處理函數中被釋放。

可是，實際狀況仍是比較複雜，當硬件偶爾出現問題不能響應驅動時，就不能完成驅動的功能。在網絡接口發送數據時也會發生一些不可預知的不響應動做，好比當網絡介質因阻塞形成的衝突，而使發送報文的動做不能獲得響應，但硬件一般不須要作此類的檢測，須要驅動用軟件的方法來實現，這就是超時傳輸機制。

2.3 傳輸超時

與真實硬件打交道的大部分驅動不得不預備處理硬件偶爾不能響應。接口可能忘記它們在作什麼，或者系統可能丟失中斷。

許多驅動經過設置定時器來處理這個問題; 若是在定時器到期時操做還沒結束, 有什麼不對了，網絡系統, 本質上是一個複雜的由大量定時器控制的狀態機的組合體。所以, 網絡代碼是一個合適的位置來檢測發送超時, 做爲它正常操做的一部分。網絡驅動不須要擔憂本身去檢測這樣的問題，相反, 它們只須要設置一個超時值, 在net_device 結構的 watchdog_timeo 成員。這個超時值, 以 jiffy 計, 應當足夠長以容納正常的發送延遲(例如網絡媒介擁塞引發的衝突)。

若是當前系統時間超過設備的 trans_start 時間至少 time-out 值, 網絡層最終調用驅動的 tx_timeout方法。這個方法的工做是是進行清除問題須要的工做而且保證任何已經開始的發送正確地完成。特別地, 驅動沒有丟失追蹤任何網絡代碼委託給它的 socket 緩存。

當發生傳送超時, 驅動必須在接口統計量中標記這個錯誤, 並安排設備被複位到一個乾淨的能發送新報文的狀態，通常驅動會調用netif_wake_queue函數從新啓動傳輸隊列。

3 數據的接收

3.1 數據接收的方式和過程

從網絡上接收報文比發送它要難一些，由於必須分配一個 sk_buff 並從一個原子性上下文中遞交給上層。網絡驅動能夠實現 2 種報文接收的模式：中斷驅動和查詢，大部分驅動採用中斷驅動技術。

大部分硬件接口經過一箇中斷處理來控制，硬件中斷處理器來發出 2 種可能的信號：一個新報文到了或者一個外出報文的發送完成了。網絡接口也可以產生中斷來指示錯誤, 例如狀態改變, 等等。

一般的中斷過程可以告知新報文到達中斷和發送完成通知的區別，經過檢查物理設備中的狀態寄存器，來判斷是那一種中斷，對於發送完成中斷更新狀態信息，釋放skb內存。而對於接收數據中斷，從數據隊列中抽取一包數據，並把它傳遞給接收函數。

注意：這裏的對設備數據的操做是在鎖得保護下完成的，作一最後還要釋放掉鎖。

3.2 選擇哪一種接收模式

那麼，既而後兩種方式來處理網絡接口發來的數據，選擇那一種呢？通常認爲中斷是比較好的一種方式，不過，若是接口接收數據太頻繁，甚至一秒中接收上千包數據，那麼系統的中斷次數就很是多，這回嚴重影響系統的性能。因此，在頻繁接收數據的狀況下，也能夠考慮使用輪詢的方式。

這樣，爲了提升linux在寬帶系統上的性能，網絡子系統開發者建立了一種基於輪詢方式的接口NAPI，它雖然在不少情況下，並不被看好，但處理高流量的高速接口時，用這種NAPI輪詢技術處理到達的每個數據包就足夠了，前提是網絡設備必須能支持這種模式，就是說一個網絡接口必須能保存多個數據包，並且中斷可以禁止中斷並能在傳輸和其餘事件上打開中斷。

3.3 Bcm4329芯片wlan驅動數據傳送

在bcm4329芯片Wlan驅動中，在函數dhd_attach被調用時，會初始化一個內核線程或一個tasklet 中斷的下半部。其實這兩種方式就是以前的中斷和輪詢方式的實現版，若是使用輪詢，驅動初始化一個內核線程dhd_dpc_thread輪詢網絡接口接收的數據，中斷下半部是中斷處理程序的延續，用於處理比較複雜費時的操做，這樣就能早點從中斷中解放出來，防止拖累系統的性能。

下面來看看這兩種方式的初始化（在dhd_attach.c）：

/* Set up the bottom halfhandler */

if (dhd_dpc_prio >= 0) {

/* Initialize DPC thread */

PROC_START(dhd_dpc_thread, dhd,&dhd->thr_dpc_ctl, 0);

} else {

/* use tasklet for dpc */

tasklet_init(&dhd->tasklet, dhd_dpc,(ulong)dhd);

dhd->thr_dpc_ctl.thr_pid =-1;

}

首先來看看輪詢方式的過程：

dhd_dpc_thread(void *data)

{

tsk_ctl_t *tsk = (tsk_ctl_t *)data;

dhd_info_t *dhd = (dhd_info_t*)tsk->parent;

/* This thread doesn't need anyuser-level access,

* so get rid of all our resources

if (dhd_dpc_prio > 0)

{

struct sched_param param;

param.sched_priority =(dhd_dpc_prio < MAX_RT_PRIO)?dhd_dpc_prio:(MAX_RT_PRIO-1);

setScheduler(current, SCHED_FIFO,&param);

}

DAEMONIZE("dhd_dpc");

/* DHD_OS_WAKE_LOCK is called indhd_sched_dpc[dhd_linux.c] down below */

/* signal: thread has started */

complete(&tsk->completed);

/* Run until signal received */

while (1) {

if (down_interruptible(&tsk->sema)== 0) {

SMP_RD_BARRIER_DEPENDS();

if (tsk->terminated){

break;

}

/* Call bus dpc unlessit indicated down (then clean stop) */

if (dhd->pub.busstate!= DHD_BUS_DOWN) {

if (dhd_bus_dpc(dhd->pub.bus)) {

up(&tsk->sema);

}

else {

DHD_OS_WAKE_UNLOCK(&dhd->pub);

}

} else {

if (dhd->pub.up)

dhd_bus_stop(dhd->pub.bus, TRUE);

DHD_OS_WAKE_UNLOCK(&dhd->pub);

}

else

break;

}

complete_and_exit(&tsk->completed, 0);

}

這裏是一個永真循環，直到接收到終止信號才中止，該線程就是經過不斷調用dhd_bus_dpc函數調用實現輪詢的，它的調用邏輯以下所示：

上面是dhd_dpc_thread的調用邏輯，最後經過netif_rx將數據提交到上層協議，那麼，還有一種中斷方式時如何實現的呢？上面只看到驅動初始化了一個tasklet，一箇中斷下半部的實例。其實在dhdsdh_probe函數中已經註冊了這個中斷處理函數：

static void *

dhdsdio_probe(uint16 venid, uint16devid, uint16 bus_no, uint16 slot,

uint16 func, uint bustype, void*regsva, osl_t * osh, void *sdh)

{

......

if (bus->intr) {

/* Register interrupt callback,but mask it (not operational yet). */

DHD_INTR(("%s: disableSDIO interrupts (not interested yet)\n", __FUNCTION__));

bcmsdh_intr_disable(sdh); //首先禁止SDIO中斷，再註冊中斷

if ((ret= bcmsdh_intr_reg(sdh, dhdsdio_isr, bus)) != 0) {

DHD_ERROR(("%s:FAILED: bcmsdh_intr_reg returned %d\n",

__FUNCTION__, ret));

goto fail;

}

DHD_INTR(("%s: registeredSDIO interrupt function ok\n", __FUNCTION__));

} else {

DHD_INFO(("%s: SDIOinterrupt function is NOT registered due to polling mode\n",

__FUNCTION__));

}

......

}

看看Dhdsdio_isr這個中斷處理函數幹了什麼？在函數的最後部分是：

#if defined(SDIO_ISR_THREAD)

DHD_TRACE(("Calling dhdsdio_dpc()from %s\n", __FUNCTION__));

DHD_OS_WAKE_LOCK(bus->dhd);

while (dhdsdio_dpc(bus));

DHD_OS_WAKE_UNLOCK(bus->dhd);

#else

bus->dpc_sched = TRUE;

dhd_sched_dpc(bus->dhd);

#endif

Dhd_sched_dpc函數在最後被調用（上面的while循環調用dhdsdio_dpc，其實和下面的這個調用函數最後的做用是同樣的，就不予詳述），這個函數的代碼以下：

void

dhd_sched_dpc(dhd_pub_t *dhdp)

{

dhd_info_t *dhd = (dhd_info_t*)dhdp->info;

DHD_OS_WAKE_LOCK(dhdp);

#ifdef DHDTHREAD

if (dhd->thr_dpc_ctl.thr_pid >=0) {

up(&dhd->thr_dpc_ctl.sema);

return;

}

#endif /* DHDTHREAD */

tasklet_schedule(&dhd->tasklet);

}

就是觸發一箇中斷的下半部tasklet，讓cpu選擇在一個合適的時候調用dhd_dpc函數，這個函數會調用dhd_bus_dpc，而後進入上面流程圖的調用邏輯。

詳細的數據處理過程不詳細敘述，能夠參考源碼來具體分析。

4 電源管理相關的調用邏輯

電源管理始終是手機等移動設備最重要的一個功能，尤爲對於Android這種智能手機或者說手機電腦化的設備，電源管理更顯得十分重要。

Linux一直在傳統的PC和服務器市場上有很好的應用，也有了比較好的電源管理框架，可是對於智能手機等嵌入式設備來講，Linux標準的電源管理就顯得不是很適用了，有許多須要改進的地方。Android在這方面作了一些比較好的嘗試，添加了一些新的特性，包括 wake_lock，early_supend等。這裏對wake_lock不作介紹，只介紹WIFI模塊在系統將要或正在進入休眠的一些動做，感興趣的話能夠本身查閱android的電源管理相關文章。

在介紹實質內容以前，先來看看android的電源管理的實現基礎：Linux系統的電源管理Suspend框架跟 Linux系統的驅動模型（Linux DriverModel）是相關的，也是基於Linux的驅動模型來實現的，下面的圖描述了Linux系統電源管理的Suspend系統框架，Linux 的Suspend系統分爲兩部分，一部分是平臺無關的核心層，另外一個是平臺相關的平臺層。操做接口都在平臺無關的核心層裏了，平臺相關部分會使用 Suspend API將本身的操做函數註冊進Suspend核心層裏。

根據Linux系統驅動模型，Device結構描述了一個設備，device_driver是設備的驅動，而 class、type和bus分別描述了設備所屬的類別、類型和總線。而設備的電源管理也根據此模型分爲class級的、type級的、bus級的和驅動級的。若是一個設備的class或者bus確切的知道如何管理一個設備的電源的時候，驅動級別的suspend/resume就能夠爲空了。這極大的提升了電源管理的高效性和靈活性。

對於android平臺上整個系統是如何一步一步進入休眠的，我這裏不作詳細介紹，只做出它的大體流程圖：

此流程圖顯示了系統的休眠的全過程，對WIFI模塊來講，咱們主要關注early_suspend和suspend以及相應的喚醒過程。當系統屏幕超時或用戶（亮屏時）按power鍵，系統進入休眠流程（這裏不討論可能的中途退出休眠的其它因素），即在沒有進程持有wakelock狀況下，首先進入 early_suspend流程。

Early_suspend流程的實現基礎是：android電源管理系統中定義了一個early_suspend結構鏈表，裏面存放了全部系統中註冊了的early_suspend實例，即若是一個模塊要在系統進入early_suspend狀態有所動做，就必須註冊一個 early_suspend實例。在WIFI驅動模塊中，當驅動流程走到dhd_attach函數時，有相應的early_suspend註冊代碼：

Path: dhd/sys/dhd_linux.c

dhd_pub_t *

dhd_attach(osl_t *osh, structdhd_bus *bus, uint bus_hdrlen)

{

......

#ifdef CONFIG_HAS_EARLYSUSPEND

dhd->early_suspend.level =EARLY_SUSPEND_LEVEL_BLANK_SCREEN + 20;

dhd->early_suspend.suspend = dhd_early_suspend;

dhd->early_suspend.resume = dhd_late_resume;

register_early_suspend(&dhd->early_suspend);

dhd_state |= DHD_ATTACH_STATE_EARLYSUSPEND_DONE;

#endif

......

}

紅色區域初始化了dhd結構的兩個early_suspend函數，並將其註冊到電源管理系統。early_suspend的休眠函數的代碼以下：

static void dhd_early_suspend(structearly_suspend *h)

{

struct dhd_info *dhd = container_of(h,struct dhd_info, early_suspend);

DHD_TRACE(("%s: enter\n",__FUNCTION__));

if (dhd)

dhd_suspend_resume_helper(dhd, 1);

}

調用dhd_suspend_resume_helper函數，別看函數名中有resume單詞，其實early_suspend和late_resume都是經過這個函數實現功能的：

static void dhd_suspend_resume_helper(structdhd_info *dhd, int val)

{

dhd_pub_t *dhdp = &dhd->pub;

DHD_OS_WAKE_LOCK(dhdp);

/* Set flag when early suspend wascalled */

dhdp->in_suspend = val;

if ((!dhdp->suspend_disable_flag)&& (dhd_check_ap_wfd_mode_set(dhdp) == FALSE))

dhd_set_suspend(val, dhdp);

DHD_OS_WAKE_UNLOCK(dhdp);

}

#if defined(CONFIG_HAS_EARLYSUSPEND) //看這裏，若是系統配置了EARLYSUSPEND ，則系統會使用這部分代碼，其實early_suspend是android對linux內核的電源管理的優化，因此若是你使用的是android平臺，必定要配置該選項

static int dhd_set_suspend(intvalue, dhd_pub_t *dhd)

{

......

if (dhd && dhd->up) {

if(value && dhd->in_suspend) { //early_suspend

/* Kernelsuspended */

DHD_ERROR(("%s: force extra Suspend setting \n",__FUNCTION__));

dhd_wl_ioctl_cmd(dhd,WLC_SET_PM, (char *)&power_mode,

sizeof(power_mode), TRUE, 0);

/* Enablepacket filter, only allow unicast packet to send up */

dhd_set_packet_filter(1, dhd);

/* If DTIM skipis set up as default, force it to wake

* each thirdDTIM for better power savings. Note that

* one sideeffect is a chance to miss BC/MC packet.

bcn_li_dtim =dhd_get_dtim_skip(dhd);

bcm_mkiovar("bcn_li_dtim",(char *)&bcn_li_dtim,

4,iovbuf, sizeof(iovbuf));

dhd_wl_ioctl_cmd(dhd,WLC_SET_VAR, iovbuf, sizeof(iovbuf), TRUE, 0);

/* Disable firmwareroaming during suspend */

bcm_mkiovar("roam_off", (char *)&roamvar, 4,

iovbuf,sizeof(iovbuf));

dhd_wl_ioctl_cmd(dhd, WLC_SET_VAR, iovbuf, sizeof(iovbuf), TRUE, 0);

} else { //late_resume

/* Kernelresumed */

DHD_TRACE(("%s: Remove extra suspend setting \n",__FUNCTION__));

power_mode =PM_FAST;

dhd_wl_ioctl_cmd(dhd, WLC_SET_PM, (char *)&power_mode,

sizeof(power_mode), TRUE, 0);

/* disable pktfilter */

dhd_set_packet_filter(0,dhd);

/* restorepre-suspend setting for dtim_skip */

bcm_mkiovar("bcn_li_dtim", (char *)&dhd->dtim_skip,

4, iovbuf, sizeof(iovbuf));

dhd_wl_ioctl_cmd(dhd,WLC_SET_VAR, iovbuf, sizeof(iovbuf), TRUE, 0);

roamvar =dhd_roam_disable;

bcm_mkiovar("roam_off", (char *)&roamvar, 4, iovbuf,

sizeof(iovbuf));

dhd_wl_ioctl_cmd(dhd,WLC_SET_VAR, iovbuf, sizeof(iovbuf), TRUE, 0);

}

return 0;

}

#endif

具體作什麼內容，能夠不用過多理會，通常只是會對該模塊作些最基本的低功耗設置，其實真正的低功耗設置時在suspend中完成的。通常的模塊也不須要註冊early_suspend實例，可是背光燈，鍵盤LED和LCD屏是必定要在註冊的。

Early_suspend註冊成功後，會被掛接到電源管理系統中的一個鏈表上，當系統進入early_suspend流程時，會逐一調用該鏈表中的每一個實例的early_suspend回調函數，使設備進入相應的狀態。在完成early_suspend流程後，系統檢測wake_lock（也是被鏈表管理，其實不止一個），若是沒有進程持有wake_lock包括main_wake_lock，系統進入suspend流程。

一樣，suspend流程的實施也是須要系統支持的，須要實現電源管理的模塊須要實現suspend和resume兩個函數，並註冊到系統中，對於WIFI設備的電源管理函數的註冊在調用wifi_add_dev函數時被註冊：

Path：wl/sys/wl_android.c

static struct platform_driverwifi_device = {

.probe = wifi_probe,

.remove =wifi_remove,

.suspend = wifi_suspend,

.resume = wifi_resume,

.driver = {

.name = "bcmdhd_wlan",

}

};

static struct platform_driverwifi_device_legacy = {

.probe = wifi_probe,

.remove = wifi_remove,

.suspend =wifi_suspend,

.resume = wifi_resume,

.driver = {

.name = "bcm4329_wlan",

}

};

static int wifi_add_dev(void)

{

DHD_TRACE(("## Callingplatform_driver_register\n"));

platform_driver_register(&wifi_device);

platform_driver_register(&wifi_device_legacy);

return 0;

}

Wifi_suspend和wifi_resume隨着wifi_device設備的註冊而註冊，這樣當系統進入suspend流程後，就能夠調用每一個設備上的電源管理函數來使設備進入休眠狀態了。

Wifi設備的休眠：

static int wifi_suspend(structplatform_device *pdev, pm_message_t state)

{

DHD_TRACE(("##> %s\n",__FUNCTION__));

#if (LINUX_VERSION_CODE <=KERNEL_VERSION(2, 6, 39)) && defined(OOB_INTR_ONLY)

bcmsdh_oob_intr_set(0);

#endif

return 0;

}

static int wifi_resume(structplatform_device *pdev)

{

DHD_TRACE(("##> %s\n",__FUNCTION__));

#if (LINUX_VERSION_CODE <=KERNEL_VERSION(2, 6, 39)) && defined(OOB_INTR_ONLY)

if (dhd_os_check_if_up(bcmsdh_get_drvdata()))

bcmsdh_oob_intr_set(1);

#endif

return 0;

}

上面的兩個電源管理函數都調用bcmsdh_oob_intr_set函數，可是傳遞的參數不一樣，在wifi_suspend函數中傳遞0，表示禁止wifi設備對應的oob中斷，而wifi_resume的做用偏偏相反。

Bcmsdh_oob_intr_set函數的定義以下：

PATH：bcmsdio/sys/bcmsdh_linux.c

#if defined(OOB_INTR_ONLY) //該中斷的使用須要配置

void bcmsdh_oob_intr_set(bool enable)

{

static bool curstate = 1;

unsigned long flags;

spin_lock_irqsave(&sdhcinfo->irq_lock, flags);

if (curstate != enable) {

if (enable)

enable_irq(sdhcinfo->oob_irq);

else

disable_irq_nosync(sdhcinfo->oob_irq);

curstate =enable;

}

spin_unlock_irqrestore(&sdhcinfo->irq_lock, flags);

}

此中斷是在打開wifi網絡設備的時候被註冊的，流程以下：

static int

dhd_open(struct net_device *net)

{

......

if (dhd->pub.busstate !=DHD_BUS_DATA) {

/* try to bring up bus*/

if ((ret = dhd_bus_start(&dhd->pub)) !=0) {

DHD_ERROR(("%s: failed with code %d\n", __FUNCTION__, ret));

ret = -1;

goto exit;

}

......

}

dhd_bus_start(dhd_pub_t *dhdp)

{

......

#if defined(OOB_INTR_ONLY)

/* Host registration for OOB interrupt*/

if(bcmsdh_register_oob_intr(dhdp)) {

......

}

在系統進入suspend狀態後，wifi設備進入禁止中斷狀態，再也不接收處理網絡發來的數據，系統進入sleep狀態，固然還有不少cpu在 suspend以後進入sleep狀態，但此時系統clock中斷並無被禁止，並且pmu還正常工做，以期對power鍵和充電器鏈接的檢測。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。