Wifi模块全总结

WIFI学习总结

2 WLAN技术 .............................................................................................................................. 3 802.11协议简述 ....................................................................................................................... 3

2.1.1 概述 ................................................................................................................... 3

3 802.11四种主要物理组件 ....................................................................................................... 4

3.1 工作站（Station） ....................................................................................................... 4

3.2 接入点（Access Point） .............................................................................................. 4

3.3 无线媒介（Wireless Medium） .................................................................................. 4

3.4 分布式系统（Distribution System） ........................................................................... 4

4 WIFI适配层 ............................................................................................................................. 5

5 wpa_supplicant.......................................................................................................................... 6

5.1 wpa_ctrl的作用 ............................................................................................................ 6

5.2 WPA_SUPPLICANT .................................................................................................... 6

5.2.1 概念 ................................................................................................................... 6

5.2.2 Wpa_supplicant与驱动的交互 ........................................................................ 6

6 Wpa_cli调试工具 .................................................................................................................... 7

6.1 启动wpa_supplicant ..................................................................................................... 7

6.2 连接wpa_cli到wpa_supplicant .................................................................................. 7

6.3 示例 ............................................................................................................................... 8

6.3.1 无密钥认证AP ................................................................................................. 8

6.3.2 WEP认证AP ................................................................................................... 8

6.3.3 WPA-PSK/WPA2-PSK认证AP ...................................................................... 8

6.3.4 隐藏AP ............................................................................................................. 9

7 Wifi模块解析和启动流程 ....................................................................................................... 9

7.1 框架分析 ....................................................................................................................... 9

7.2 Wifi启动流程 ............................................................................................................ 11

8 WLAN驱动结构介绍 ............................................................................................................ 22

8.1 SDIO驱动 .................................................................................................................. 22

8.2 Boardcom无线通讯芯片 ........................................................................................... 23

8.2.1 概述 ................................................................................................................. 23

8.2.2 源码 ................................................................................................................. 23

8.3 详细接口及代码分析 ................................................................................................. 24

8.3.1 WIFI驱动流程分析 ....................................................................................... 24

8.3.2 WIFI设备注册流程 ....................................................................................... 25

8.3.3 WIFI驱动流程（二） ................................................................................... 40

8.3.4 网络设备注册流程 ......................................................................................... 43

9 IOCTL的调用逻辑 ................................................................................................................ 48

10 数据的传送 ..................................................................................................................... 56

10.1 数据传送过程简述 ................................................................................................. 56

10.2 Bcm4329芯片wlan驱动数据传送 .......................................................................... 57

10.3 传输超时 ................................................................................................................. 59 1

11 数据的接收 ..................................................................................................................... 59

11.1 数据接收的方式和过程 ............................................................................................. 59

11.2 选择哪种接收模式 ..................................................................................................... 60

11.3 Bcm4329芯片wlan驱动数据传送 .......................................................................... 60

12 电源管理相关的调用逻辑 ............................................................................................. 65

13 Android平台的Wifi模块移植要点 ............................................................................. 74

13.1 Wifi结构 .................................................................................................................... 74

13.2 Wifi模块环境 ............................................................................................................ 75

13.3 Wifi模块的编译......................................................................................................... 75

13.3.1 Wifi驱动源码 ................................................................................................. 75

13.3.2 在android平台添加BCM43xx驱动 ............................................................ 75

13.3.3 编译wifi驱动源码 ........................................................................................ 79

13.3.4 在android中使用BCM43xx ......................................................................... 80

1 WLAN技术

WLAN是英文WirelessLAN的缩写，就是无线局域网的意思。无线以太网技术是一种基于无线传输的局域网技术，与有线网络技术相比，具有灵活、建网迅速、个人化等特点。将这一技术应用于电信网的接入网领域，能够方便、灵活地为用户提供网络接入，适合于用户流动性较大、有数据业务需求的公共场所、高端的企业及家庭用户、需要临时建网的场合以及难以采用有线接入方式的环境等。

2 802.11协议简述

2.1.1 概述

作为全球公认的局域网权威，IEEE802工作组建立的标准在过去二十年内在局域网领域独领风骚。这些协议包括了802.3Ethernet协议、802.5TokenRing协议、802.3z100BASE－T快速以太网协议。在19xx年，经过了7年的工作以后，IEEE发布了802.11协议，这也是在无线局域网领域内的第一个国际上被认可的协议。

在19xx年9月，他们又提出了802.11b"HighRate"协议，用来对802.11协议进行补充，802.11b在802.11的1Mbps和2Mbps速率下又增加了5.5Mbps和11Mbps两个新的网络吞吐速率。利用802.11b，移动用户能够获得同Ethernet一样的性能、网络吞吐率、可用性。这个基于标准的技术使得管理员可以根据环境选择合适的局域网技术来构造自己的网络，满足他们的商业用户和其他用户的需求。802.11协议主要工作在ISO协议的最低两层上，并在物理层上进行了一些改动，加入了高速数字传输的特性和连接的稳定性。

主要内容：

1.802.11工作方式

2.802.11物理层

3.802.11b的增强物理层

4.802.11数字链路层

5.联合结构、蜂窝结构和漫游

3 802.11四种主要物理组件

3.1 工作站（Station）

构建网络的主要目的是为了在工作站间传送数据。所谓工作站，是指配备无线网络接口的计算设备。

3.2 接入点（Access Point）

802.11网络所使用的帧必须经过转换，方能被传递至其他不同类型的网络。具备无线至有线的桥接功能的设备称为接入点，接入点的功能不仅于此，但桥接最为重要。

3.3 无线媒介（Wireless Medium）

802.11标准以无线媒介在工作站之间传递帧。其所定义的物理层不只是一种，802.11最初标准化了两种射频物理层以及一种红外线物理层。

3.4 分布式系统（Distribution System）

当几个接入点串联以覆盖较大区域时，彼此之间必须相互通信以掌握移动式工作站的行踪。分布式系统属于802.11的逻辑组件，负责将帧转送至目的地。

下图为802.11网络的基本服务集（basic service set），其中包含了这四种物理组件。

4 WIFI适配层

里面定义很多字符串变量和适配层的接口实现，是对wpa_supplicant程序通信的接口封装，用来完成上层和wpa_supplicant的通信，头文件在libhardware/include/hardware下，这里的函数用来向JNI的本地实现提供调用接口。

这里的函数，我把它们分为四类函数：

一类是命令相关的（控制）函数，就是在JNI层android_XXX_Command()函数所调用的Wifi_Command()函数，调用流程如下：

android_XXX_command()=>docommand()=>wifi_command()=>wifi_send_command()=>wpa_ctrl_require()。

二类是监听函数，即Wifi_wait_for_event()函数，调用流程如下：android_net_wifi_Waitforevent()=> wifi_wait_for_event()=>wpa_ctrl_recv()。

三就是WPA_SUPPLICANT的启动，连接，关闭函数

四是驱动的加载和卸载函数

Wifi模块全总结

5 wpa_supplicant

5.1 wpa_ctrl的作用

定义了两类套接字和一个管道，并分别实现了和wpa_supplicant的通信，而在实际的实现中采用的都是套接字的方式，因此wpa_supplicant适配层和wpa_supplicant层是通过socket通讯的。

要是从wifi.c中真的很难看出它和wpa_supplicant有什么关系，和它联系密切的就是这个wpa_ctrl.h文件，这里面定义了一个类wpa_ctrl，这个类中声明了两个Socket套接口，一个是本地一个是要连接的套接口，wpa_ctrl与wpa_supplicant的通信就需要socket来帮忙了，而wpa_supplicant就是通过调用 wpa_ctrl.h中定义的函数和wpa_supplicant进行通讯的，wpa_ctrl类（其实是其中的两个socket）就是他们之间的桥梁。

5.2 WPA_SUPPLICANT

5.2.1 概念

wpa_supplicant本是开源项目源码，被谷歌修改后加入android移动平台，它主要是用来支持WEP，WPA/WPA2和WAPI无线协议和加密认证的，而实际上的工作内容是通过socket（不管是wpa_supplicant与上层还是wpa_supplicant与驱动都采用socket通讯）与驱动交互上报数据给用户，而用户可以通过socket发送命令给wpa_supplicant调动驱动来对WiFi芯片操作。简单的说，wpa_supplicant就是WiFi驱动和用户的中转站外加对协议和加密认证的支持。

5.2.2 Wpa_supplicant与驱动的交互

5.2.2.1 wpa_supplicant.c

首先定义一个驱动操作数组externstruct wpa_driver_ops *wpa_supplicant_drivers[]，然后是系列wpa_supplicant_XXX()函数，很多函数里面调用 wpa_drv_XXX()函数，这些函数是wpa_supplicant_i.h中实现的函数。几乎每个函数都需要一个wpa_supplicant结构，对其进行所有的控制和通信操作。

5.2.2.2 Wpa_supplicant_i.h

其中定义了一个重要数据结构wpa_supplicant，其中有一个重要的driver成 6

员，它是wpa_driver_ops类型，可以被用来调用抽象层的接口。接下来是系列函数声明，这些函数声明在wpa_supplicant.c中实现，然后就是wpa_drv_XXX函数，这些函数就是在 wpa_supplicant.c中被wpa_supplicant_xxx函数调用的，而这些wpa_drv_xxx函数也都有一个 wpa_supplicant结构的变量指针，用来调用封装的抽象接口，而这些抽象接口的实现在driver_wext.c中（如果使用的汉斯WEXT驱动）。

这里要注意的是：在wpa_suppliant.c文件中定义的很多函数是在该头文件中声明的，而不是在wpa_supplicant.h中声明的。

5.2.2.3 Driver_wext.c

对wpa_drvier_ops的个函数的具体实现，该结构指针在wpa_supplicant注册一个网络接口时会被初始化赋予指定的操作指针，wpa_supplicant.c中的wpa_supplicant_xxx函数通过wpa_supplicant结构中的该操作指针调用WEXT的实现接口。

就是在该文件中，创建了三个socket：ioctrl_socket，event_socket和mlme_socket，它们分别有自己的用途，如ioctrl_socket用于发送控制命令，event_socket用于监听驱动传来的event事件等。Wpa_supplicant通过这三个socket与wifi驱动关联，这里的socket同fd（文件描述符）类似。

6 Wpa_cli调试工具

6.1 启动wpa_supplicant

使用下面命令启动wpa_supplicant: wpa_supplicant -Dwext

-c/data/misc/wifi/wpa_supplicant.conf -iwlan0 -C/data/system/wpa_supplicant

为了确保wpa_supplicant真的启动起来了，使用“ps”命令查看。

6.2 连接wpa_cli到wpa_supplicant

wpa_cli -p/data/system/wpa_supplicant -iwlan0

然后，就可以使用wpa_cli调试工具进行wifi调试了，下面列出了一些常用的调试命令：

>scan //扫描周围的AP

//显示扫描结果

//显示当前的连接状态信息

//终止wpa_supplicant

//退出wpa_cli

//返回可用network id

//设置网络 >scan_results >status >terminate >quit >add_network >set_network <network id> <variable> <value>

>select_network <network id>

>disable_network <network id>

>enable_network <network id> //选择网络，禁用其它网络 //禁用网络 //启用网络

6.3 示例 6.3.1 无密钥认证AP

>add_network (返回可用network id, 假定返回0)

>set_network 0 ssid “666”

>set_network 0 key_mgmt NONE

>enable_network 0

>quit

如果上面的操作正确，我们会连接到一个AP，它的SSID为“666”，现在需要一个IP来访问internet：

dhcpcd wlan0

成功获取IP后，即可连上internet。 6.3.2 WEP认证AP

>add_network (假设返回1)

>set_network 1 ssid “666”

>set_network 1 key_mgmt NONE

>set_network 1 wep_key0 “ap passwork”

>set_network 1 wep_tx_keyidx 0

>select_network 1 （如果你已经连上了其它的AP，那么就需要这个命令来禁用其它的网络）

>enable_network 1

然后同上获取IP，连接到internet上。

6.3.3 WPA-PSK/WPA2-PSK认证AP

>add_network (假定返回2)

>set_network 2 ssid “666”

>set_network 2 psk “your pre-shared key”

>select_network 2

>enable_network 2

还有其它的命令进一步设置网络，不过wpa_supplicant已经给了我们一些默认的配置。

6.3.4 隐藏AP

原则上应该只要在上面的基础上去set_network netid scan_ssid 1即可，测试过无加密的Hidden AP，WEP/WPA/WPA2应该道理一样。

7 Wifi模块解析和启动流程

7.1 框架分析

WIFI整体框架如图所示：

首先，用户程序使用WifiManager类来管理Wifi模块，它能够获得Wifi模 10

Wifi模块全总结

块的状态，配置和控制Wifi模块，而所有这些操作都要依赖 Wifiservice类来实现。

WifiService和WifiMonitor类是Wifi框架的核心，如图所示。下面先来看看WifiService是什么时候，怎么被创建和初始化的。

在systemServer启动之后，它会创建一个 ConnectivityServer对象，这个对象的构造函数会创建一个WifiService的实例，代码如下所示：

framework/base/services/java/com/android/server/ConnectivityService.java

{

……

case ConnectivityManager.TYPE_WIFI:

if (DBG) Slog.v(TAG, "Starting Wifi Service.");

WifiStateTracker wst = new WifiStateTracker(context, mHandler); //创建WifiStateTracker实例

WifiService wifiService = newWifiService(context, wst);//创建WifiService实例 ServiceManager.addService(Context.WIFI_SERVICE, wifiService); //向服务管理系统添加Wifi服务

wifiService.startWifi(); //启动Wifi

mNetTrackers[ConnectivityManager.TYPE_WIFI] = wst;

wst.startMonitoring(); //启动WifiMonitor中的WifiThread线程

……

}

WifiService的主要工作：WifiMonitor和Wpa_supplicant的启动和关闭，向Wpa_supplicant发送命令。

WifiMonitor的主要工作：阻塞监听并接收来自Wpa_supplicant的消息，然后发送给WifiStateTracker。

上面两个线程通过AF_UNIX套接字和Wpa_supplicant通信，在通信过程中有两种连接方式：控制连接和监听连接。它们创建代码如下：

ctrl_conn =wpa_ctrl_open(ifname);

.. .. ..

monitor_conn = wpa_ctrl_open(ifname);

7.2 Wifi启动流程

（1）使能Wifi

要想使用Wifi模块，必须首先使能Wifi，当你第一次按下Wifi使能按 11

钮时，WirelessSettings会实例化一个WifiEnabler 对象，实例化代码如下： packages/apps/settings/src/com/android/settings/WirelessSettings.java

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

……

CheckBoxPreferencewifi = (CheckBoxPreference) findPreference(KEY_TOGGLE_WIFI);

mWifiEnabler= new WifiEnabler(this, wifi);

……

}

WifiEnabler类的定义大致如下，它实现了一个监听接口，当WifiEnabler对象被初始化后，它监听到你按键的动作，会调用响应函数 onPreferenceChange（），这个函数会调用WifiManager的setWifiEnabled（）函数。 public class WifiEnabler implementsPreference.OnPreferenceChangeListener {

……

public boolean onPreferenceChange(Preference preference,Object value) {

booleanenable = (Boolean) value;

……

if (mWifiManager.setWifiEnabled(enable)) {

mCheckBox.setEnabled(false);

……

}

……

}

我们都知道Wifimanager只是个服务代理，所以它会调用WifiService的setWifiEnabled（）函数，而这个函数会调用 sendEnableMessage（）函数，了解android消息处理机制的都知道，这个函数最终会给自己发送一个 MESSAGE_ENABLE_WIFI的消息，被WifiService里面定义的handlermessage()函数处理，会调用 setWifiEnabledBlocking（）函数。下面是调用流程：

mWifiEnabler.onpreferencechange()=>mWifiManage.setWifienabled()=>mWifiService.setWifiEnabled()=>mWifiService.sendEnableMessage()=>mWifiService.handleMessage()=>mWifiService.setWifiEnabledBlocking().

在 setWifiEnabledBlocking()函数中主要做如下工作：加载Wifi驱动，启动wpa_supplicant，注册广播接收器，启动 WifiThread监听线程。代码如下：

……

if (enable) {

if (!mWifiStateTracker.loadDriver()) {

Slog.e(TAG, "Failed toload Wi-Fi driver.");

setWifiEnabledState(WIFI_STATE_UNKNOWN, uid);

return false;

}

if (!mWifiStateTracker.startSupplicant()) {

mWifiStateTracker.unloadDriver();

Slog.e(TAG, "Failed tostart supplicant daemon.");

setWifiEnabledState(WIFI_STATE_UNKNOWN, uid);

return false;

}

registerForBroadcasts();

mWifiStateTracker.startEventLoop();

……

至此，Wifi使能结束，自动进入扫描阶段。

(2) 扫描AP

当驱动加载成功后，如果配置文件的AP_SCAN = 1，扫描会自动开始，WifiMonitor将会从supplicant收到一个消息EVENT_DRIVER_STATE_CHANGED，调用 handleDriverEvent（），然后调用mWifiStateTracker.notifyDriverStarted()，该函数向消息队列添加EVENT_DRIVER_STATE_CHANGED，handlermessage()函数处理消息时调用scan()函数，并通过 WifiNative将扫描命令发送到wpa_supplicant。

Frameworks/base/wifi/java/android/net/wifi/WifiMonitor.java

private void handleDriverEvent(Stringstate) { if (state == null) {

return;

}

if (state.equals("STOPPED")) {

mWifiStateTracker.notifyDriverStopped();

} else if (state.equals("STARTED")) {

mWifiStateTracker.notifyDriverStarted();

} else if (state.equals("HANGED")) {

mWifiStateTracker.notifyDriverHung();

}

Frameworks/base/wifi/java/android/net/wifi/WifiStateTracker.java

case EVENT_DRIVER_STATE_CHANGED:

switch(msg.arg1) {

case DRIVER_STARTED:

/**

*Set the number of allowed radio channels according

*to the system setting, since it gets reset by the

*driver upon changing to the STARTED state.

setNumAllowedChannels();

synchronized (this) {

if (mRunState == RUN_STATE_STARTING) {

mRunState = RUN_STATE_RUNNING;

if (!mIsScanOnly) {

reconnectCommand();

} else {

// In somesituations, supplicant needs to be kickstarted to

// start thebackground scanning

scan(true);

}

break;

上面是启动Wifi 时，自动进行的AP的扫描，用户当然也可以手动扫描AP，这部分实现在WifiService里面，WifiService通过startScan()接口函数发送扫描命令到supplicant。

Frameworks/base/wifi/java/android/net/wifi/WifiStateTracker.java

public boolean startScan(booleanforceActive) {

enforceChangePermission();

switch (mWifiStateTracker.getSupplicantState()) {

case DISCONNECTED:

case INACTIVE:

case SCANNING:

case DORMANT:

break;

default:

mWifiStateTracker.setScanResultHandling(

WifiStateTracker.SUPPL_SCAN_HANDLING_LIST_ONLY);

break;

}

return mWifiStateTracker.scan(forceActive);

}

然后下面的流程同上面的自动扫描，我们来分析一下手动扫描从哪里开始的。我们应该知道手动扫描是通过菜单键的扫描键来响应的，而响应该动作的 14

应该是 WifiSettings类中Scanner类的handlerMessage()函数，它调用WifiManager的 startScanActive()，这才调用WifiService的startScan()。

packages/apps/Settings/src/com/android/settings/wifiwifisettings.java public boolean onCreateOptionsMenu(Menu menu) {

menu.add(Menu.NONE, MENU_ID_SCAN, 0, R.string.wifi_menu_scan)

.setIcon(R.drawable.ic_menu_scan_network);

menu.add(Menu.NONE, MENU_ID_ADVANCED, 0, R.string.wifi_menu_advanced) .setIcon(android.R.drawable.ic_menu_manage);

return super.onCreateOptionsMenu(menu);

}

当按下菜单键时，WifiSettings就会调用这个函数绘制菜单。如果选择扫描按钮，WifiSettings会调用 onOptionsItemSelected()。

packages/apps/Settings/src/com/android/settings/wifiwifisettings.java public booleanonOptionsItemSelected(MenuItem item) {

switch (item.getItemId()) {

case MENU_ID_SCAN:

if(mWifiManager.isWifiEnabled()) {

mScanner.resume();

}

return true;

case MENU_ID_ADVANCED:

startActivity(new Intent(this,AdvancedSettings.class));

return true;

}

return super.onOptionsItemSelected(item);

}

private class Scanner extends Handler {

private int mRetry = 0;

void resume() {

if (!hasMessages(0)) {

sendEmptyMessage(0);

}

void pause() {

mRetry = 0;

mAccessPoints.setProgress(false);

removeMessages(0);

}

@Override

public void handleMessage(Message message) {

if (mWifiManager.startScanActive()){

mRetry = 0;

} else if (++mRetry >= 3) {

mRetry = 0;

Toast.makeText(WifiSettings.this, R.string.wifi_fail_to_scan,

Toast.LENGTH_LONG).show();

return;

}

mAccessPoints.setProgress(mRetry != 0);

sendEmptyMessageDelayed(0, 6000);

}

这里的mWifiManager.startScanActive()就会调用WifiService里的startScan（）函数，下面的流程和上面的一样，这里不赘述。

当supplicant完成了这个扫描命令后，它会发送一个消息给上层，提醒他们扫描已经完成，WifiMonitor会接收到这消息，然后再发送给WifiStateTracker。

Frameworks/base/wifi/java/android/net/wifi/WifiMonitor.java void handleEvent(int event, String remainder) {

switch (event) {

caseDISCONNECTED:

handleNetworkStateChange(NetworkInfo.DetailedState.DISCONNECTED,remainder);

break;

case CONNECTED:

handleNetworkStateChange(NetworkInfo.DetailedState.CONNECTED,remainder);

break;

case SCAN_RESULTS:

mWifiStateTracker.notifyScanResultsAvailable();

break;

case UNKNOWN:

break;

}

WifiStateTracker将会广播 SCAN_RESULTS_AVAILABLE_ACTION消息： 16

Frameworks/base/wifi/java/android/net/wifi/WifiStateTracker.java public voidhandleMessage(Message msg) {

Intent intent;

……

case EVENT_SCAN_RESULTS_AVAILABLE:

if(ActivityManagerNative.isSystemReady()) {

mContext.sendBroadcast(new Intent(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION));

}

sendScanResultsAvailable();

/**

* On receiving the first scanresults after connecting to

* the supplicant, switch scanmode over to passive.

setScanMode(false);

break;

……

｝

由于WifiSettings类注册了intent，能够处理SCAN_RESULTS_AVAILABLE_ACTION消息，它会调用 handleEvent()，调用流程如下所示。

WifiSettings.handleEvent()

mWifiManager.getScanResults() =>WifiSettings.updateAccessPoints() => => mService.getScanResults()=> mWifiStateTracker.scanResults() => WifiNative.scanResultsCommand()……

将获取AP列表的命令发送到supplicant，然后supplicant通过Socket发送扫描结果，由上层接收并显示。这和前面的消息获取流程基本相同。

(3)配置，连接AP

当用户选择一个活跃的AP时，WifiSettings响应打开一个对话框来配置AP，比如加密方法和连接AP的验证模式。配置好AP后，WifiService添加或更新网络连接到特定的AP。

packages/apps/settings/src/com/android/settings/wifi/WifiSetttings.java

public booleanonPreferenceTreeClick(PreferenceScreen screen, Preference preference) { if (preference instanceof AccessPoint) {

mSelected = (AccessPoint) preference;

showDialog(mSelected, false);

} else if (preference == mAddNetwork) {

mSelected = null;

showDialog(null, true);

} else if (preference == mNotifyOpenNetworks) {

Secure.putInt(getContentResolver(),

Secure.WIFI_NETWORKS_AVAILABLE_NOTIFICATION_ON,

mNotifyOpenNetworks.isChecked() ? 1 : 0);

} else {

return super.onPreferenceTreeClick(screen, preference);

}

return true;

}

配置好以后，当按下“Connect Press”时，WifiSettings通过发送LIST_NETWORK命令到supplicant来检查该网络是否配置。如果没有该网络或没有配置它，WifiService调用addorUpdateNetwork（）函数来添加或更新网络，然后发送命令给supplicant，连接到这个网络。下面是从响应连接按钮到WifiService发送连接命令的代码：

packages/apps/settings/src/com/android/settings/wifi/WifiSetttings.java public void onClick(DialogInterfacedialogInterface, int button) {

if (button == WifiDialog.BUTTON_FORGET && mSelected != null) {

forget(mSelected.networkId);

} else if (button == WifiDialog.BUTTON_SUBMIT && mDialog !=null) {

WifiConfiguration config = mDialog.getConfig();

if (config == null) {

if (mSelected != null&& !requireKeyStore(mSelected.getConfig())) {

connect(mSelected.networkId);

}

} else if (config.networkId != -1) {

if (mSelected != null) {

mWifiManager.updateNetwork(config);

saveNetworks();

}

} else {

int networkId =mWifiManager.addNetwork(config);

if (networkId != -1) {

mWifiManager.enableNetwork(networkId, false);

config.networkId =networkId;

if (mDialog.edit || requireKeyStore(config)){

saveNetworks();

} else {

connect(networkId);

}

Frameworks\base\wifi\java\android\net\wifi\WifiManager.java public intupdateNetwork(WifiConfiguration config) {

if(config == null || config.networkId < 0) {

return -1;

}

return addOrUpdateNetwork(config);

}

private intaddOrUpdateNetwork(WifiConfiguration config) {

try {

return mService.addOrUpdateNetwork(config);

} catch (RemoteException e) {

return -1;

}

WifiService.addOrUpdateNetwork()通过调用 mWifiStateTracker.setNetworkVariable()将连接命令发送到Wpa_supplicant。

（4）获取IP地址

当连接到supplicant后，WifiMonitor就会通知WifiStateTracker。

Frameworks/base/wifi/java/android/net/wifi/WifiMonitor.java

Public void Run(){

if (connectToSupplicant()) {

// Send a message indicatingthat it is now possible to send commands

// to the supplicant

mWifiStateTracker.notifySupplicantConnection();

} else {

mWifiStateTracker.notifySupplicantLost();

return;

}

……

}

WifiStateTracker 发送EVENT_SUPPLICANT_CONNECTION消息到消息队列，这个消息有自己的handlermessage()函数处理，它会启动一个 DHCP线程，而这个线程会一直等待一个消息事件，来启动DHCP协议分配IP地址。

frameworks/base/wifi/java/android/net/wifi/WifiStateTracker.java

void notifySupplicantConnection() {

sendEmptyMessage(EVENT_SUPPLICANT_CONNECTION);

}

public void handleMessage(Message msg) {

Intent intent;

switch (msg.what) {

case EVENT_SUPPLICANT_CONNECTION:

……

HandlerThread dhcpThread = newHandlerThread("DHCP Handler Thread"); dhcpThread.start();

mDhcpTarget = newDhcpHandler(dhcpThread.getLooper(), this);

……

}

当 Wpa_supplicant连接到AP后，它会发送一个消息给上层来通知连接成功，WifiMonitor会接受到这个消息并上报给 WifiStateTracker。

Frameworks/base/wifi/java/android/net/wifi/WifiMonitor.java void handleEvent(int event, String remainder) {

switch (event) {

case DISCONNECTED:

handleNetworkStateChange(NetworkInfo.DetailedState.DISCONNECTED,remainder);

break;

case CONNECTED:

handleNetworkStateChange(NetworkInfo.DetailedState.CONNECTED,remainder);

break;

……

}

private void handleNetworkStateChange(NetworkInfo.DetailedState newState, String data) { StringBSSID = null;

intnetworkId = -1;

if(newState == NetworkInfo.DetailedState.CONNECTED) {

Matcher match = mConnectedEventPattern.matcher(data);

if(!match.find()) {

if (Config.LOGD) Log.d(TAG, "Could not find BSSID in CONNECTEDevent string");

}else {

BSSID = match.group(1);

try {

networkId = Integer.parseInt(match.group(2));

} catch (NumberFormatException e) {

networkId = -1;

}

mWifiStateTracker.notifyStateChange(newState,BSSID, networkId); }

void notifyStateChange(DetailedState newState, StringBSSID, int networkId) { Messagemsg = Message.obtain(

this, EVENT_NETWORK_STATE_CHANGED,

newNetworkStateChangeResult(newState, BSSID, networkId)); msg.sendToTarget();

}

caseEVENT_NETWORK_STATE_CHANGED:

……

configureInterface();

……

private void configureInterface() {

checkPollTimer();

mLastSignalLevel = -1;

if(!mUseStaticIp) { //使用DHCP线程动态IP

if(!mHaveIpAddress && !mObtainingIpAddress) {

mObtainingIpAddress = true;

//发送启动DHCP线程获取IP

mDhcpTarget.sendEmptyMessage(EVENT_DHCP_START); }

} else { //使用静态IP，IP信息从mDhcpInfo中获取

intevent;

if(NetworkUtils.configureInterface(mInterfaceName, mDhcpInfo)) { mHaveIpAddress = true;

event = EVENT_INTERFACE_CONFIGURATION_SUCCEEDED; if (LOCAL_LOGD) Log.v(TAG, "Static IP configurationsucceeded"); }else {

mHaveIpAddress = false;

event = EVENT_INTERFACE_CONFIGURATION_FAILED; if (LOCAL_LOGD) Log.v(TAG, "Static IP configuration failed"); }

sendEmptyMessage(event); //发送IP获得成功消息事件 21

}

DhcpThread获取EVENT_DHCP_START消息事件后，调用handleMessage（）函数，启动DHCP获取IP地址的服务。 public void handleMessage(Message msg) {

intevent;

switch (msg.what) {

case EVENT_DHCP_START:

……

Log.d(TAG, "DhcpHandler: DHCP requeststarted");

//启动一个DHCPclient的精灵进程，为mInterfaceName请求分配一个IP地//址 if (NetworkUtils.runDhcp(mInterfaceName, mDhcpInfo)) {

event= EVENT_INTERFACE_CONFIGURATION_SUCCEEDED;

if(LOCAL_LOGD) Log.v(TAG, "DhcpHandler: DHCP request succeeded");

} else {

event= EVENT_INTERFACE_CONFIGURATION_FAILED;

Log.i(TAG,"DhcpHandler: DHCP request failed: " +

NetworkUtils.getDhcpError());

}

……

}

这里调用了一个NetworkUtils.runDhcp（）函数，NetworkUtils类是一个网络服务的辅助类，它主要定义了一些本地接口，这些接口会通过他们的JNI层android_net_NetUtils.cpp文件和DHCP client通信，并获取IP地址。

至此，IP 地址获取完毕，Wifi启动流程结束。

8 WLAN驱动结构介绍

8.1 SDIO驱动

在drivers/mmc下面是mmc卡，SD卡和SDIO卡驱动部分，其中包括host驱动，card驱动和core部分，由于网络接口卡挂接在SDIO总线上，所以在此之前我们先看一下SDIO的驱动结构。其驱动在drivers/mmc目录下的结构为：

|-- mmc

| |-- card

| |-- core

| |-- host

主要关注的目录是core目录，这个目录是真个驱动的核心目录，是媒体卡的通用代码部分，包括core.c，host.c和sdio.c等。CORE 层完成了不同协议和规范的实现，并为 HOST 层的驱动提供了接口函数，该目录完成sdio总线的注册操作，相应的ops操作，以及支持mmc的代码。详细的情况将在函数接口部分详细讨论。

Host目录是不同平台根据平台的特性而编写的host驱动。

8.2 Boardcom无线通讯芯片

8.2.1 概述

全球有线和无线通信半导体市场的领导者Broadcom（博通）公司（Nasdaq：BRCM）宣布，推出最新无线组合芯片BCM4330，该芯片可支持更多媒体形式和数据应用，且不会增大智能手机、平板电脑及其他移动设备的尺寸或缩短其电池寿命。BCM4330在单个芯片上集成了业界领先的Broadcom 802.11n Wi-Fi、蓝牙和FM无线技术，与分立式半导体器件组成的解决方案相比，在成本、尺寸、功耗和性能上有显著优势，是移动设备的理想选择。

BCM4330采用了新的Wi-Fi和蓝牙标准，可支持新的、令人振奋的应用。例如，Broadcom BCM4330是业界第一款经过蓝牙4.0标准认证的组合芯片解决方案，集成了蓝牙低功耗（BLE）标准。该标准使蓝牙技术能以超低功耗运行，因此BCM4330非常适用于需要很长电池寿命的系统，如无线传感器、医疗和健身监控设备等。BCM4330还支持Wi-Fi Direct?和蓝牙高速（HS）标准，因此采用BCM4330的移动设备能直接相互通信，而不必先连接到接入点、成为传统网络的一部分，从而为很多无线设备之间新的应用和使用模式创造了机会。

Broadcom一直支持所有主流的操作系统（OS）平台，如Microsoft Windows和Windows Phone、Google Chrome、Android等等，而且不仅是BCM4330，所有蓝牙、WLAN和GPS芯片组都提供这样的支持。

8.2.2 源码

Bcm4330驱动源码一般被厂商单独提供，如果要在开发的LINUX系统中（当然它还支持多种平台）使用该源码，可以添加到linux kernel源码树里，也可以单独组织存放，可以直接编译到kernel，也可以编译成模块，然后再系统启动的流程中或其他适当的实际加载到kernel中，一般建议单独组织并编译成模块在需要的时候加载如kernel。

|-- src

| |-- bcmsdio

| |-- dhd

| |-- dongle

| |-- include

| |-- shared

| |-- wl

这里主要内容到bcmsdio，dhd和wl三个目录下，bcm4330驱动的入口在dhd/sys/dhd_linux.c文件中的dhd_module()函数，设备的初始化和相关驱动注册都从这里开始，

8.3 详细接口及代码分析

8.3.1 WIFI驱动流程分析

以boardcom bcm4329芯片驱动为例，相应的函数流程图如下：

Wifi模块全总结

8.3.2 WIFI设备注册流程

Wifi模块全总结

Platform_driver_register(wifi_device[_legacy])的调用将wifi_device[_legacy]驱动注册到系统中，wifi_device_legacy是为了兼容老版本的驱动。

Path: wl/sys/wl_android.c

Static struct Platform_driver wifi_device = {

.probe = wifi_probe

.remove = wifi_remove

.suspend = wifi_supend

.resume = wifi_resume

.driver = {

.name = “bcmdhd_wlan”

}

Static struct Platform_driver wifi_device_legacy = {

.probe = wifi_probe

.remove = wifi_remove

.suspend = wifi_supend

.resume = wifi_resume

.driver = {

.name = “bcm4329_wlan”

}

上面的展示了wifi平台设备驱动的注册过程，那么在平台相关的代码区应该有wifi作为平台设备被初始化和注册的地方：

Path: kernel/arch/arm/mach-msm/msm_ static struct resource mahimahi_wifi_resources[] = {

[0] = {

.name = "bcm4329_wlan_irq",

.start = MSM_GPIO_TO_INT(MAHIMAHI_GPIO_WIFI_IRQ),

.end = MSM_GPIO_TO_INT(MAHIMAHI_GPIO_WIFI_IRQ),

.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL | IORESOURCE_IRQ_SHAREABLE,

};

static struct wifi_platform_data mahimahi_wifi_control = {

.set_power = mahimahi_wifi_power,

.set_reset = mahimahi_wifi_reset,

.set_carddetect = mahimahi_wifi_set_carddetect,

.mem_prealloc = mahimahi_wifi_mem_prealloc,

};

static struct platform_device mahimahi_wifi_device = {

.name = "bcm4329_wlan",

.id = 1,

.num_resources = ARRAY_SIZE(mahimahi_wifi_resources),

.resource = mahimahi_wifi_resources,

.dev = {

.platform_data = &mahimahi_wifi_control,

};

上面是对wifi_device设备的初始化，下面是对该设备的注册：

static int __init mahimahi_wifi_init(void)

{

int ret;

if (!machine_is_mahimahi())

return 0;

printk("%s: start\n", __func__);

mahimahi_wifi_update_nvs("sd_oobonly=1\r\n", 0);

mahimahi_wifi_update_nvs("btc_params70=0x32\r\n", 1);

mahimahi_init_wifi_mem();

ret = platform_device_register(&mahimahi_wifi_device);

return ret;

}

late_initcall(mahimahi_wifi_init); //表明在系统启动的后期会自动调用加载该模块这样，通过上面的初始化和注册流程，wifi设备作为平台设备和驱动就可以握手成功了，这里的平台驱动只是对wifi设备的简单管理，如对wifi设备的挂起和恢复等操作了。但是在wifi设备初始化之前是不能够被挂起和恢复的，那么wifi设备是如何初始化的呢？

Path: wl/sys/wl_android.c static int wifi_probe(struct platform_device *pdev)

{

struct wifi_platform_data *wifi_ctrl =

(struct wifi_platform_data *)(pdev->dev.platform_data);

DHD_ERROR(("## %s\n", __FUNCTION__));

wifi_irqres = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "bcmdhd_wlan_irq");

if (wifi_irqres == NULL)

wifi_irqres = platform_get_resource_byname(pdev,

IORESOURCE_IRQ, "bcm4329_wlan_irq");

wifi_control_data = wifi_ctrl;

wifi_set_power(1, 0); /* Power On */

wifi_set_carddetect(1); /* CardDetect (0->1) */

up(&wifi_control_sem);

return 0;

}

这是wifi平台设备驱动注册时成功匹配wifi设备后调用的函数wifi_probe()，它的主要工作就是从wifi设备中获取终端资源，并获取wifi_platform_data类型结构赋予wifi_control_data变量，这一步很重要，下面就可以看出了它的重要性。然后调用wifi_set_power和wifi_set_carddetect函数给wifi芯片上电并检测。

int wifi_set_power(int on, unsigned long msec)

{

DHD_ERROR(("%s = %d\n", __FUNCTION__, on));

if (wifi_control_data && wifi_control_data->set_power) {

wifi_control_data->set_power(on);

}

if (msec)

msleep(msec);

return 0;

}

Wifi_set_power函数中调用wifi_control_data->set_power(on)，wifi_control_data就是刚才说的那个重要变量，注意它是从wifi_device平台设备的wifi_platform_data获取的，那么看看上面的wifi_device初始化的代码： static struct platform_device mahimahi_wifi_device = {

.name = "bcm4329_wlan",

.id = 1,

.num_resources = ARRAY_SIZE(mahimahi_wifi_resources),

.resource = mahimahi_wifi_resources,

.dev = {

.platform_data = &mahimahi_wifi_control,

};

static struct wifi_platform_data mahimahi_wifi_control = {

.set_power = mahimahi_wifi_power,

.set_reset = mahimahi_wifi_reset,

.set_carddetect = mahimahi_wifi_set_carddetect,

.mem_prealloc = mahimahi_wifi_mem_prealloc,

};

所以它实际调用的是mahimahi_wifi_power函数，该函数的定义在kernel/arch/arm /mach-msm/board-mahimahi-mmc.c之中： int mahimahi_wifi_power(int on)

{

printk("%s: %d\n", __func__, on);

if (on) {

config_gpio_table(wifi_on_gpio_table,

ARRAY_SIZE(wifi_on_gpio_table));

mdelay(50);

} else {

config_gpio_table(wifi_off_gpio_table,

ARRAY_SIZE(wifi_off_gpio_table));

}

mdelay(100);

gpio_set_value(MAHIMAHI_GPIO_WIFI_SHUTDOWN_N, on);

WIFI_SHUTDOWN */

mdelay(200);

/* 28

mahimahi_wifi_power_state = on;

return 0;

}

调用gpio_set_value操作wifi芯片，给wifi芯片上电。那么来看看wifi_set_ carddetect函数究竟干了什么：

Path：wl/sys/wl_android.c static int wifi_set_carddetect(int on)

{

DHD_ERROR(("%s = %d\n", __FUNCTION__, on));

if (wifi_control_data && wifi_control_data->set_carddetect) {

wifi_control_data->set_carddetect(on);

}

return 0;

}

同样会调用wifi_device的mahimahi_wifi_set_carddetect函数：

Path: kernel/arch/arm/mach-msm/board-mahimahi-mmc.c int mahimahi_wifi_set_carddetect(int val)

{

pr_info("%s: %d\n", __func__, val);

mahimahi_wifi_cd = val;

if (wifi_status_cb) {

wifi_status_cb(val, wifi_status_cb_devid);

} else

pr_warning("%s: Nobody to notify\n", __func__);

return 0;

}

Wifi_status_cb代码： static int mahimahi_wifi_status_register(

void (*callback)(int card_present, void *dev_id), void *dev_id)

{

if (wifi_status_cb)

return -EAGAIN;

wifi_status_cb = callback;

wifi_status_cb_devid = dev_id;

return 0;

}

static unsigned int mahimahi_wifi_status(struct device *dev)

{

return mahimahi_wifi_cd;

}

static struct mmc_platform_data mahimahi_wifi_data = {

.ocr_mask = MMC_VDD_28_29,

.built_in = 1,

.status = mahimahi_wifi_status,

.register_status_notify = mahimahi_wifi_status_register,

.embedded_sdio = &mahimahi_wifi_emb_data,

};

由上面代码；不难看出会有个地方调用mahimahi_wifi_status_register设置wifi_status_cb这个回调函数，可以跟踪这个mahimahi_wifi_data结构体，来看看它被传递给了谁： int msm_add_sdcc(unsigned int controller, struct mmc_platform_data *plat,

unsigned int stat_irq, unsigned long stat_irq_flags);

int __init mahimahi_init_mmc(unsigned int sys_rev, unsigned debug_uart)

{

msm_add_sdcc(1, &mahimahi_wifi_data, 0, 0);

if (system_rev > 0)

msm_add_sdcc(2, &mahimahi_sdslot_data, 0, 0);

else {

mahimahi_sdslot_data.status = mahimahi_sdslot_status_rev0;

mahimahi_sdslot_data.register_status_notify = NULL;

set_irq_wake(MSM_GPIO_TO_INT(MAHIMAHI_GPIO_SDMC_CD_REV0_N), 1);

msm_add_sdcc(2, &mahimahi_sdslot_data,

}

可以跟踪到这里Path：kernel/arch/arm/mach-msm/devices-msm7x30.c

struct platform_device msm_device_sdc1 = {

.name = "msm_sdcc",

.id = 1,

.num_resources = ARRAY_SIZE(resources_sdc1),

.resource = resources_sdc1,

.dev = {

.coherent_dma_mask = 0xffffffff,

};

struct platform_device msm_device_sdc2 = {

.name = "msm_sdcc",

.id = 2,

.num_resources = ARRAY_SIZE(resources_sdc2),

.resource = resources_sdc2,

.dev = {

.coherent_dma_mask = 0xffffffff,

};

struct platform_device msm_device_sdc3 = {

.name = "msm_sdcc",

.id = 3,

.num_resources = ARRAY_SIZE(resources_sdc3),

.resource = resources_sdc3,

.dev = {

.coherent_dma_mask = 0xffffffff,

};

struct platform_device msm_device_sdc4 = {

.name = "msm_sdcc",

.id = 4,

.num_resources = ARRAY_SIZE(resources_sdc4),

.resource = resources_sdc4,

.dev = {

439,2-16 62%

.coherent_dma_mask = 0xffffffff,

};

static struct platform_device *msm_sdcc_devices[] __initdata = {

&msm_device_sdc1,

&msm_device_sdc2,

&msm_device_sdc3,

&msm_device_sdc4,

};

int __init msm_add_sdcc(unsigned int controller, struct mmc_platform_data *plat,

unsigned int stat_irq, unsigned long stat_irq_flags)

{

pdev = msm_sdcc_devices[controller-1]; //因为传过来的controller是1，所以下面注册的是第一个平台设备

pdev->dev.platform_data = plat; //被传递给平台设备的platform_data

res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "status_irq"); if (!res)

return -EINVAL;

else if (stat_irq) {

res->start = res->end = stat_irq;

res->flags &= ~IORESOURCE_DISABLED;

res->flags |= stat_irq_flags;

}

return platform_device_register(pdev); //如上所述

}

那么这个平台设备是什么呢，就是sd卡控制器，也就是前面说的host驱动所驱动的主机控制设备。

Path: drivers/mmc/host/msm_sdcc.c

static struct platform_driver msmsdcc_driver = {

.probe = msmsdcc_probe,

.suspend = msmsdcc_suspend,

.resume = msmsdcc_resume,

.driver = {

.name = "msm_sdcc",

};

static int __init msmsdcc_init(void)

{

return platform_driver_register(&msmsdcc_driver);

}

驱动成功匹配设备后，调用probe函数：

static int

msmsdcc_probe(struct platform_device *pdev)

{

......

if (stat_irqres && !(stat_irqres->flags & IORESOURCE_DISABLED)) {

} else if (plat->register_status_notify) {

plat->register_status_notify(msmsdcc_status_notify_cb, host); } else if (!plat->status)

......

}

msmsdcc_status_notify_cb调用msmsdcc_check_status函数： msmsdcc_status_notify_cb(int card_present, void *dev_id)

{

struct msmsdcc_host *host = dev_id;

printk(KERN_DEBUG "%s: card_present %d\n", mmc_hostname(host->mmc), card_present);

msmsdcc_check_status((unsigned long) host);

}

msmsdcc_check_status调用mmc_detect_change函数： static void

msmsdcc_check_status(unsigned long data)

{

if (status ^ host->oldstat) { pr_info("%s: Slot status change detected (%d -> %d)\n",

mmc_hostname(host->mmc), host->oldstat, status);

if (status && !host->plat->built_in)

mmc_detect_change(host->mmc, (5 * HZ) / 2);

else

mmc_detect_change(host->mmc, 0);

}

host->oldstat = status;

out:

if (host->timer.function)

mod_timer(&host->timer, jiffies + HZ);

}

可以看到mmc_detect_change被调用了，这个函数触发了一个延时工作： void mmc_detect_change(struct mmc_host *host, unsigned long delay)

{

mmc_schedule_delayed_work(&host->detect, delay);

}

这个时候它会在delay时间后，执行host->detect延时工作对应的函数，在host驱动注册并匹配设备成功后执行的probe函数里，会调用mmc_alloc_host动态创建一个mmc_host：

msmsdcc_probe(struct platform_device *pdev)

{

......

* Setup our host structure

mmc = mmc_alloc_host(sizeof(struct msmsdcc_host), &pdev->dev);

if (!mmc) {

ret = -ENOMEM;

goto out;

}

......

}

mmc_alloc_host初始化工作入口：

struct mmc_host *mmc_alloc_host(int extra, struct device *dev)

{

......

INIT_DELAYED_WORK(&host->detect, mmc_rescan);

......

}

mmc_rescan是core.c中一个很重要的函数，它遵照 SDIO 卡协议的 SDIO 卡启动过程，包括了非激活模式、卡识别模式和数据传输模式三种模式共九种状态的转换，你需要参照相关规范来理解。 void mmc_rescan(struct work_struct *work)

{

struct mmc_host *host =

container_of(work, struct mmc_host, detect.work);

......

mmc_power_up(host);

sdio_reset(host);

mmc_go_idle(host);

mmc_send_if_cond(host, host->ocr_avail);

* First we search for SDIO...

err = mmc_send_io_op_cond(host, 0, &ocr);

if (!err) {

if (mmc_attach_sdio(host, ocr))

mmc_power_off(host);

extend_wakelock = 1;

goto out;

}

......

}

这个mmc_attach_sdio函数很重要，它是SDIO卡的初始化的起点，主要工作包括：匹配SDIO卡的工作电压，分配并初始化mmc_card结构，然后注册mmc_card到系统中： /*

* Starting point for SDIO card init.

int mmc_attach_sdio(struct mmc_host *host, u32 ocr)

{

mmc_attach_bus(host, &mmc_sdio_ops); //初始化host的bus_ops

host->ocr = mmc_select_voltage(host, ocr); //匹配SDIO卡工作电压

* Detect and init the card.

err = mmc_sdio_init_card(host, host->ocr, NULL, 0); //检测，分配初始化mmc_card

if (err)

goto err;

card = host->card;

* If needed, disconnect card detection pull-up resistor.

err = sdio_disable_cd(card);

if (err)

goto remove;

* Initialize (but don't add) all present functions.

for (i = 0; i < funcs; i++, card->sdio_funcs++) {

#ifdef CONFIG_MMC_EMBEDDED_SDIO

if (host->embedded_sdio_data.funcs) {

struct sdio_func *tmp;

tmp = sdio_alloc_func(host->card);

if (IS_ERR(tmp))

goto remove;

tmp->num = (i + 1);

card->sdio_func[i] = tmp;

tmp->class = host->embedded_sdio_data.funcs[i].f_class;

tmp->max_blksize = host->embedded_sdio_data.funcs[i].f_maxblksize;

tmp->vendor = card->cis.vendor;

tmp->device = card->cis.device;

} else {

#endif

err = sdio_init_func(host->card, i + 1);

if (err)

goto remove;

#ifdef CONFIG_MMC_EMBEDDED_SDIO

}

#endif

}

mmc_release_host(host);

* First add the card to the driver model...

err = mmc_add_card(host->card); //添加mmc_card

if (err)

goto remove_added;

* ...then the SDIO functions.

for (i = 0;i < funcs;i++) {

err = sdio_add_func(host->card->sdio_func[i]); //将sdio_func加入系统

if (err)

goto remove_added;

}

return 0;

......

}

这样，SDIO卡已经初始化成功并添加到了驱动中。上面说的过程是在SDIO设备注册时的调用流程，mmc_rescan是整个流程主体部分，由它来完成SDIO设备的初始化和添加。其实上面的流程只是创建，初始化，添加SDIO设备的一条线，还有另外的两条线也会调用mmc_rescan函数进行SDIO设备的上述操作：

（1）加载SDIO host驱动模块

（2） SDIO设备中断

8.3.2.1 加载SDIO host驱动模块

Host作为平台设备被注册，前面也有列出相应源码： static struct platform_driver msmsdcc_driver = {

.probe = msmsdcc_probe,

.suspend = msmsdcc_suspend,

.resume = msmsdcc_resume,

.driver = {

.name = "msm_sdcc",

};

static int __init msmsdcc_init(void)

{

return platform_driver_register(&msmsdcc_driver);

}

Probe函数会调用mmc_alloc_host函数（代码前面已经贴出）来创建mmc_host结构变量，进行必要的初始化之后，调用mmc_add_host函数将它添加到驱动里面：

int mmc_add_host(struct mmc_host *host)

{

err = device_add(&host->class_dev);

if (err)

return err;

mmc_start_host(host);

if (!(host->pm_flags & MMC_PM_IGNORE_PM_NOTIFY))

register_pm_notifier(&host->pm_notify);

return 0;

}

Mmc_start_host定义如下： void mmc_start_host(struct mmc_host *host)

{

mmc_power_off(host);

mmc_detect_change(host, 0);

}

mmc_power_off 中对 ios 进行了设置，然后调用 mmc_set_ios(host);

host->ios.power_mode = MMC_POWER_OFF;

host->ios.bus_width = MMC_BUS_WIDTH_1;

host->ios.timing = MMC_TIMING_LEGACY;

mmc_set_ios(host);

mmc_set_ios(host) 中的关键语句 host->ops->set_ios(host, ios)，实际上在host驱动的probe函数中就已经对host->ops进行了初始化： ??

* Setup MMC host structure

mmc->ops = &msmsdcc_ops;

static const struct mmc_host_ops msmsdcc_ops = {

.request = msmsdcc_request,

.set_ios = msmsdcc_set_ios,

.enable_sdio_irq = msmsdcc_enable_sdio_irq,

};

所以实际上调用的是msmsdcc_set_ios，关于这个函数就不介绍了，可以参考源码，再看 mmc_detect_change(host, 0)，最后一句是：

mmc_schedule_delayed_work(&host->detect, delay);

实际上就是调用我们前面说的延时函数 mmc_rescan，后面的流程是一样的。

8.3.2.2 SDIO设备中断

SDIO设备通过SDIO总线与host相连，SDIO总线的DAT[1]即pin8可以作为中断线使用，当SDIO设备向host产生中断时，host会对终端做出相应的动作，在host驱动的probe函数中申请并注册相应的中断函数：

static int

msmsdcc_probe(struct platform_device *pdev)

{

......

cmd_irqres = platform_get_resource_byname(pdev, IORESOURCE_IRQ,

"cmd_irq");

pio_irqres = platform_get_resource_byname(pdev, IORESOURCE_IRQ,

"pio_irq");

stat_irqres = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "status_irq");

......

if (stat_irqres && !(stat_irqres->flags & IORESOURCE_DISABLED)) {

unsigned long irqflags = IRQF_SHARED |

(stat_irqres->flags & IRQF_TRIGGER_MASK);

host->stat_irq = stat_irqres->start;

ret = request_irq(host->stat_irq,

msmsdcc_platform_status_irq,

irqflags,

DRIVER_NAME " (slot)",

host);

if (ret) {

pr_err("%s: Unable to get slot IRQ %d (%d)\n",

mmc_hostname(mmc), host->stat_irq, ret);

goto clk_disable;

}

......

}

当产生相应的中断时调用msmsdcc_platform_status_irq中断处理函数，这个函数的处理流程：

msmsdcc_platform_status_irq—>

msmsdcc_check_status?

mmc_detect_change?

mmc_rescan?

那么，这里为何调用mmc_rescan呢？因为前面说过mmc_rescanrescan函数主要用于SDIO设备的初始化，如果SDIO设备产生中断不应该是已经初始化可以使用了吗？其实mmc_rescan还有其它的工作，从函数名就能看出来它还有再扫描检测功能，即如果设备产生了中断，mmc_rescan函数一开始就会再次检测所有挂接在该host上的所有SDIO设备，确认是否存在，如果不存在就做相应的释放工作，以确保数据的一致性。如果检测到了新的设备那么它就会创建一个新的mmc_card，初始化并添加该设备。

中断引发的调用mmc_rescan动作的意义：实现了SDIO设备的热插拔功能。

Wifi模块全总结

此调用流程由dhd_bus_register发起，通过sdio_register_driver注册一个sdio设备驱动，然后通过dhdsdio_probe初始化并注册一个网络设备，网络设备的注册标志着wifi驱动已经成功加载，关于网络设备的创建，初始化和注册后面会有详细介绍，先来理一下上面的调用流程，：

dhd_mudule_init—> //path: dhd/sys/dhd_linux.c

Dhd_bus_register? // dhd/sys/dhd_sdio.c

Bcmsdh_register? // bcmsdio/sys/bcmsdh_linux.c

Sdio_function_init? // bcmsdio/sys/bcmsdh_sdmmc_linux.c

Sdio_register_driver? // bcmsdio/sys/bcmsdh_sdmmc_linux.c

Bcmsdh_sdmmc_probe?//bcmsdio/sys/bcmsdh_sdmmc_linu

x.c

Bcmsdh_probe? //bcmsdio/sys/bcmsdh_linux.c

Bcmsdio_probe? //dhd/sys/dhd_sdio.c

这里注意上面两个红色标记的函数，sdio_register_driver注册了一个sdio设备，在匹配成功后调用bcmsdh_sdmmc_probe函数，这个函数会调用bcmsdh_probe。这里有一点要注意：浏览bcmsdh_linux.c文件可以看出，在bcmsdh_register函数中，当定义了BCMLXSDMMC宏时，会调用sdio_function_init函数，否则调用driver_register函数： int

bcmsdh_register(bcmsdh_driver_t *driver)

{

int error = 0;

drvinfo = *driver; //注意这里，后面会介绍到它的用处

#if defined(BCMPLATFORM_BUS)

#if defined(BCMLXSDMMC)

SDLX_MSG(("Linux Kernel SDIO/MMC Driver\n"));

error = sdio_function_init();

#else

SDLX_MSG(("Intel PXA270 SDIO Driver\n"));

error = driver_register(&bcmsdh_driver);

#endif /* defined(BCMLXSDMMC) */

return error;

#endif /* defined(BCMPLATFORM_BUS) */

#if !defined(BCMPLATFORM_BUS) && !defined(BCMLXSDMMC)

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

if (!(error = pci_module_init(&bcmsdh_pci_driver)))

return 0;

#else

if (!(error = pci_register_driver(&bcmsdh_pci_driver)))

return 0;

#endif

SDLX_MSG(("%s: pci_module_init failed 0x%x\n", __FUNCTION__, error)); #endif /* BCMPLATFORM_BUS */

return error;

}

上面的流程中有sdio_function_init的调用出现，所以这里实际上BCMLXSDMMC宏被定义了，bcmsdh_probe函数只是作为一个普通函数被调用，如果不定义该宏，那么bcmsdh_probe函数会被作为驱动匹配设备后第一个调用的函数而被自动调用。

再看看dhdsdio_probe函数调用的玄机，从上面的bcmsdh_register函数可以看出它的参数被传递给了drvinfo，看看bcmsdh_register的调用地方： static bcmsdh_driver_t dhd_sdio = {

dhdsdio_probe,

dhdsdio_disconnect

};

int

dhd_bus_register(void)

{

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

return bcmsdh_register(&dhd_sdio);

}

上面传递的参数是dhd_sdio结构变量，被用两个函数初始化了，那么哪一个是attach呢？需要找到定义bcmsdh_driver_t结构定义的地方： Path：src/include/bcmsdh.h

/* callback functions */

typedef struct {

/* attach to device */ void *(*attach)(uint16 vend_id, uint16 dev_id, uint16 bus, uint16 slot,

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

void * param);

/* detach from device */

void (*detach)(void *ch);

} bcmsdh_driver_t;

没错，就是第一个dhdsdio_probe函数，再来看看什么地方调用了这个attach函数：

Path: bcmsdio/sys/bcmsdh_linux.c

#ifndef BCMLXSDMMC

static

#endif /* BCMLXSDMMC */

int bcmsdh_probe(struct device *dev)

{

......

if (!(sdhc->ch = drvinfo.attach((vendevid >> 16),

(vendevid & 0xFFFF), 0, 0, 0, 0,

Wifi模块全总结

(void *)regs, NULL, sdh))) {

SDLX_MSG(("%s: device attach failed\n", __FUNCTION__));

goto err;

}

return 0;

......

}

红色部分的函数调用是drvinfo.attach，就是上面传递过来的dhdsdio_probe函数了，仔细阅读你会发现上面那个bcmsdh_driver_t结构体定义的地方有个说明，即把该结构的成员函数当做callback函数来使用，这就是它的用意所在。

8.3.4 网络设备注册流程

上面是网络设备注册流程，在dhdsdio_probe函数中先后对dhd_attach和dhd_net_attach两个函数调用，dhd_attach主要用于创建和初始化dhd_info_t和net_device两个结构变量，然后调用dhd_add_if将创建的net_device变量添加到dhd_info_t变量的iflist列表中（支持多接口）。

Dhd_attach的流程如下： dhd_pub_t *

dhd_attach(osl_t *osh, struct dhd_bus *bus, uint bus_hdrlen)

{

dhd_info_t *dhd = NULL;

struct net_device *net = NULL;

......

/* Allocate etherdev, including space for private structure */

if (!(net = alloc_etherdev(sizeof(dhd)))) { //网络设备的创建

DHD_ERROR(("%s: OOM - alloc_etherdev\n", __FUNCTION__)); goto fail;

}

dhd_state |= DHD_ATTACH_STATE_NET_ALLOC;

/* Allocate primary dhd_info */

if (!(dhd = MALLOC(osh, sizeof(dhd_info_t)))) { //dhd的创建

DHD_ERROR(("%s: OOM - alloc dhd_info\n", __FUNCTION__)); goto fail;

}

......

/* Set network interface name if it was provided as module parameter */

if (iface_name[0]) {

int len;

char ch;

strncpy(net->name, iface_name, IFNAMSIZ);

net->name[IFNAMSIZ - 1] = 0;

len = strlen(net->name);

ch = net->name[len - 1];

if ((ch > '9' || ch < '0') && (len < IFNAMSIZ - 2))

strcat(net->name, "%d");

}

if (dhd_add_if(dhd, 0, (void *)net, net->name, NULL, 0, 0) == DHD_BAD_IF) //将前面创建的net添加到iflist列表中

goto fail;

dhd_state |= DHD_ATTACH_STATE_ADD_IF;

......

Memcpy(netdev_priv(net), &dhd, sizeof(dhd)); //关联dhd和net

//dhd的初始化工作

}

Dhd_add_if的添加网络接口流程： int

dhd_add_if(dhd_info_t *dhd, int ifidx, void *handle, char *name,

uint8 *mac_addr, uint32 flags, uint8 bssidx)

{

dhd_if_t *ifp;

DHD_TRACE(("%s: idx %d, handle->%p\n", __FUNCTION__, ifidx, handle));

ASSERT(dhd && (ifidx < DHD_MAX_IFS));

ifp = dhd->iflist[ifidx];

if (ifp != NULL) {

if (ifp->net != NULL) {

netif_stop_queue(ifp->net);

unregister_netdev(ifp->net);

free_netdev(ifp->net); //如果已经存在，释放net成员 }

} else

if ((ifp = MALLOC(dhd->pub.osh, sizeof(dhd_if_t))) == NULL) { DHD_ERROR(("%s: OOM - dhd_if_t\n", __FUNCTION__)); //否则，创建一个dhd_if_t结构变量

return -ENOMEM;

}

memset(ifp, 0, sizeof(dhd_if_t));

ifp->info = dhd; //进行系列初始化，添加工作

dhd->iflist[ifidx] = ifp;

strncpy(ifp->name, name, IFNAMSIZ);

ifp->name[IFNAMSIZ] = '\0';

if (mac_addr != NULL)

memcpy(&ifp->mac_addr, mac_addr, ETHER_ADDR_LEN);

if (handle == NULL) {

ifp->state = DHD_IF_ADD;

ifp->idx = ifidx;

ifp->bssidx = bssidx;

ASSERT(&dhd->thr_sysioc_ctl.thr_pid >= 0);

up(&dhd->thr_sysioc_ctl.sema);

} else

ifp->net = (struct net_device *)handle; //handle即一个net_device变量

return 0;

}

这样，一个net_device网路设备就被添加到了接口管理列表中了，但是这是网路设备还没有完成初始化和注册工作，bcmsdio_probe函数随后对dhd_net_attach的调用完成了这个操作： int

dhd_net_attach(dhd_pub_t *dhdp, int ifidx)

{

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

struct net_device *net = NULL;

int err = 0;

uint8 temp_addr[ETHER_ADDR_LEN] = { 0x00, 0x90, 0x4c, 0x11, 0x22, 0x33 };

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

ASSERT(dhd && dhd->iflist[ifidx]);

net = dhd->iflist[ifidx]->net; //首先从刚才添加的接口列表中取出net，然后进行下面的系列初始化工作

ASSERT(net);

//根据内核版本信息，选择对net成员函数的初始化方式，假设是2.6.30的版本

#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

/* Ok, link into the network layer... */

if (ifidx == 0) {

* device functions for the primary interface only

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

net->open = dhd_open;

net->stop = dhd_stop;

#else

net->netdev_ops = &dhd_ops_pri;

#endif

} else {

* We have to use the primary MAC for virtual interfaces

3417,1-8 66%

memcpy(temp_addr, dhd->iflist[ifidx]->mac_addr,

ETHER_ADDR_LEN);

* Android sets the locally administered bit to indicate that this is a

* portable hotspot. This will not work in simultaneous AP/STA

mode,

* nor with P2P. Need to set the Donlge's MAC address, and then

use that.

if (!memcmp(temp_addr, dhd->iflist[0]->mac_addr,

ETHER_ADDR_LEN)) {

DHD_ERROR(("%s interface [%s]: set locally

administered bit in MAC\n",

__func__, net->name));

temp_addr[0] |= 0x02;

}

net->hard_header_len = ETH_HLEN + dhd->pub.hdrlen;

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 24)

net->ethtool_ops = &dhd_ethtool_ops;

#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 24) */

#if defined(CONFIG_WIRELESS_EXT)

#if WIRELESS_EXT < 19

net->get_wireless_stats = dhd_get_wireless_stats;

#endif /* WIRELESS_EXT < 19 */

#if WIRELESS_EXT > 12

net->wireless_handlers = (struct iw_handler_def *)&wl_iw_handler_def;

//这里的初始化工作很重要，之后的ioctl流程会涉及到对它的使用

#endif /* WIRELESS_EXT > 12 */

#endif /* defined(CONFIG_WIRELESS_EXT) */

dhd->pub.rxsz = DBUS_RX_BUFFER_SIZE_DHD(net);

//设置设备地址

memcpy(net->dev_addr, temp_addr, ETHER_ADDR_LEN);

if ((err = register_netdev(net)) != 0) { //注册net

DHD_ERROR(("couldn't register the net device, err %d\n", err));

goto fail;

}

到这里net网络设备就被注册到系统中了，设备准备好了就好对设备进行访问了

9 IOCTL的调用逻辑

之所以要分析这个，是因为上层wpa_supplicant和WIFI驱动打交道的方式，多半是通过ioctl的方式进行的，所以看看它的调用逻辑（这里只列出其主要的调用逻辑）：

上面便是用户ioctl调用的流程图，它最终分为两条线即有两种支持，选择那一条或两条都选（个人感觉最好选第2条线，因为它最后也是会调用到相应的函数的，而且还有其它更多的命令支持），从实际的代码来看，如果dev->netdev_ops ->ndo_do_ioctl被初始化了，那么它一定会被调用，是否被初始化，在前面选择对net结构变量的初始化方式中有讨论过。

下面来具体看看该调用流程，首先说明下，上面的流程主要实现在kernel/net/wireless/wext_core.c文件中，这是wireless的协议层实现，恰好我们在wpa_supplicant中通常选择的驱动类型也是wext，它的入口函数是 49

Wifi模块全总结

wext_ioctl_dispatch： /* entry point from dev ioctl */

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

unsigned int cmd, struct iw_request_info *info, wext_ioctl_func standard,

wext_ioctl_func private)

{

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(struct net *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(struct iwreq)))

return -EFAULT;

return ret;

}

实际上传递的就是ioctl_standard_call和ioctl_private_call两个函数，在看看 50

wireless_process_ioctl函数，这个函数很重要，下面做重点分析： static int wireless_process_ioctl(struct net *net, struct ifreq *ifr,

unsigned int cmd,

struct iw_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 in dev_ioctl() before calling us.

* The copy_to/from_user() of ifr is also 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 the generic case...

* Note that 'cmd' is already filtered in dev_ioctl() with

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

if (cmd == SIOCGIWSTATS)

return standard(dev, iwr, cmd, info,

&iw_handler_get_iwstats); //如果是状态查询命令，调用该函数（回调函数中的一个）

#ifdef CONFIG_WEXT_PRIV

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

return standard(dev, iwr, cmd, info,

iw_handler_get_private); //如果是专有命令，调用回调函数，同上

#endif

/* Basic check */

if (!netif_device_present(dev))

return -ENODEV;

/* New driver API : try to find the handler */

handler = get_handler(dev, cmd); //根据cmd参数，从dev成员中查询相应的处理函数

if (handler) {

/* Standard and private are not the 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 ioctl handler */

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_handler get_handler(struct net_device *dev, unsigned int cmd)

{

/* Don't "optimise" the following 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)

return handlers->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 int ioctl_standard_call(struct net_device * dev,

struct iwreq *iwr,

unsigned int cmd,

struct iw_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 user space data or not */

if (descr->header_type != IW_HEADER_TYPE_POINT) {

/* No extra arguments. Trivial to handle */

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

/* Generate an event to notify listeners 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 and defined */

if (ret == -EIWCOMMIT)

ret = call_commit_handler(dev);

/* Here, we will generate the appropriate 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(struct net_device *net, struct ifreq *ifr, int cmd)

{

......#if defined(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也有相应的处理函数。

10 数据的传送

10.1 数据传送过程简述

传送指的是通过一个网络连接发送一个报文的行为.。无论何时内核需要传送一个数据报文, 它都必须调用驱动的 hard_start_xmit 方法将数据放在外出队列上。

每个内核处理的报文都包含在一个 socket缓存结构( 结构 sk_buff )里, 定义见<linux/skbuff.h>。这个结构从 Unix 抽象中得名, 用来代表一个网络连接 56

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(发送成功)。

10.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, int ifidx, 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就在这个中断处理函数中被释放。

但是，实际情况还是比较复杂，当硬件偶尔出现问题不能响应驱动时，就不能完成驱动的功能。在网络接口发送数据时也会发生一些不可预知的不响应动作，比如当网络介质因阻塞造成的冲突，而使发送报文的动作不能得到响应，但硬件通常不需要做此类的检测，需要驱动用软件的方法来实现，这就是超时传输机制。

10.3 传输超时

与真实硬件打交道的大部分驱动不得不预备处理硬件偶尔不能响应。接口可能忘记它们在做什么，或者系统可能丢失中断。

许多驱动通过设置定时器来处理这个问题; 如果在定时器到期时操作还没结束, 有什么不对了，网络系统, 本质上是一个复杂的由大量定时器控制的状态机的组合体。因此, 网络代码是一个合适的位置来检测发送超时, 作为它正常操作的一部分。网络驱动不需要担心自己去检测这样的问题，相反, 它们只需要设置一个超时值, 在net_device 结构的 watchdog_timeo 成员。这个超时值, 以 jiffy 计, 应当足够长以容纳正常的发送延迟(例如网络媒介拥塞引起的冲突)。

如果当前系统时间超过设备的 trans_start 时间至少 time-out 值, 网络层最终调用驱动的 tx_timeout方法。这个方法的工作是是进行清除问题需要的工作并且保证任何已经开始的发送正确地完成。特别地, 驱动没有丢失追踪任何网络代码委托给它的 socket 缓存。

当发生传送超时, 驱动必须在接口统计量中标记这个错误, 并安排设备被复位到一个干净的能发送新报文的状态，一般驱动会调用netif_wake_queue函数重新启动传输队列。

11 数据的接收

11.1 数据接收的方式和过程

从网络上接收报文比发送它要难一些，因为必须分配一个 sk_buff 并从一个 59

原子性上下文中递交给上层。网络驱动可以实现 2 种报文接收的模式：中断驱动和查询，大部分驱动采用中断驱动技术。

大部分硬件接口通过一个中断处理来控制，硬件中断处理器来发出 2 种可能的信号：一个新报文到了或者一个外出报文的发送完成了。网络接口也能够产生中断来指示错误, 例如状态改变, 等等。

通常的中断过程能够告知新报文到达中断和发送完成通知的区别，通过检查物理设备中的状态寄存器，来判断是那一种中断，对于发送完成中断更新状态信息，释放skb内存。而对于接收数据中断，从数据队列中抽取一包数据，并把它传递给接收函数。

注意：这里的对设备数据的操作是在锁得保护下完成的，做一最后还要释放掉锁。

11.2 选择哪种接收模式

那么，既然后两种方式来处理网络接口发来的数据，选择那一种呢？一般认为中断是比较好的一种方式，不过，如果接口接收数据太频繁，甚至一秒中接收上千包数据，那么系统的中断次数就非常多，这回严重影响系统的性能。所以，在频繁接收数据的情况下，也可以考虑使用轮询的方式。

这样，为了提高linux在宽带系统上的性能，网络子系统开发者创建了一种基于轮询方式的接口NAPI，它虽然在很多情况下，并不被看好，但处理高流量的高速接口时，用这种NAPI轮询技术处理到达的每一个数据包就足够了，前提是网络设备必须能支持这种模式，就是说一个网络接口必须能保存多个数据包，而且中断能够禁止中断并能在传输和其他事件上打开中断。

11.3 Bcm4329芯片wlan驱动数据传送

在bcm4329芯片Wlan驱动中，在函数dhd_attach被调用时，会初始化一个内核线程或一个tasklet中断的下半部。其实这两种方式就是之前的中断和轮询方式的实现版，如果使用轮询，驱动初始化一个内核线程dhd_dpc_thread轮询网络接口接收的数据，中断下半部是中断处理程序的延续，用于处理比较复杂费时的操作，这样就能早点从中断中解放出来，防止拖累系统的性能。

下面来看看这两种方式的初始化（在dhd_attach.c）：

/* Set up the bottom half handler */

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 any user-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 in dhd_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 unless it indicated down (then clean stop) */ if (dhd->pub.busstate != DHD_BUS_DOWN) { 61

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, uint16 devid, 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: disable SDIO 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 63

Wifi模块全总结

returned %d\n",

__FUNCTION__, ret));

goto fail;

}

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

} else {

DHD_INFO(("%s: SDIO interrupt 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，然后进入上面流程图的调用逻辑。

详细的数据处理过程不详细叙述，可以参考源码来具体分析。

12 电源管理相关的调用逻辑

电源管理始终是手机等移动设备最重要的一个功能，尤其对于Android这种智能手机或者说手机电脑化的设备，电源管理更显得十分重要。

Linux一直在传统的PC和服务器市场上有很好的应用，也有了比较好的电源管理框架，但是对于智能手机等嵌入式设备来说，Linux标准的电源管理就显得不是很适用了，有许多需要改进的地方。Android在这方面做了一些比较好的尝试，添加了一些新的特性，包括wake_lock，early_supend等。这里对wake_lock不做介绍，只介绍WIFI模块在系统将要或正在进入休眠的一些动作，感兴趣的话可以自己查阅android的电源管理相关文章。

在介绍实质内容之前，先来看看android的电源管理的实现基础：Linux系统的电源管理Suspend框架跟Linux系统的驱动模型（Linux Driver Model）是相关的，也是基于Linux的驱动模型来实现的，下面的图描述了Linux系统电源管理的Suspend系统框架，Linux的Suspend系统分为两部分，一部分是平台无关的核心层，另一个是平台相关的平台层。操作接口都在平台无关的核心层里了，平台相关部分会使用Suspend API将自己的操作函数注册进Suspend核心层里。 65

根据Linux系统驱动模型，Device结构描述了一个设备，device_driver是设备的驱动，而class、type和bus分别描述了设备所属的类别、类型和总线。而设备的电源管理也根据此模型分为class级的、type级的、bus级的和驱动级的。如果一个设备的class或者bus确切的知道如何管理一个设备的电源的时候，驱动级别的suspend/resume就可以为空了。这极大的提高了电源管理的高效性和灵活性。

对于android平台上整个系统是如何一步一步进入休眠的，我这里不做详细介绍，只作出它的大致流程图：

Wifi模块全总结

某进程持有

Wakelock

此流程图显示了系统的休眠的全过程，对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, struct dhd_bus *bus, uint bus_hdrlen)

{

......

#ifdef CONFIG_HAS_EARLYSUSPEND

dhd->early_suspend.level = EARLY_SUSPEND_LEVEL_BLANK_SCREEN + 20;

Wifi模块全总结

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(struct early_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(struct dhd_info *dhd, int val)

{

dhd_pub_t *dhdp = &dhd->pub;

DHD_OS_WAKE_LOCK(dhdp);

/* Set flag when early suspend was called */

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(int value, dhd_pub_t *dhd)

{

......

if (dhd && dhd->up) {

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

/* Kernel suspended */

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);

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

dhd_set_packet_filter(1, dhd);

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

* each third DTIM for better power savings. Note that

* one side effect 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 firmware roaming 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

/* Kernel resumed */

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 pkt filter */

dhd_set_packet_filter(0, dhd);

/* restore pre-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_driver wifi_device = {

.probe = wifi_probe,

.remove = wifi_remove,

.suspend = wifi_suspend,

.resume = wifi_resume,

.driver = {

.name = "bcmdhd_wlan",

}

};

static struct platform_driver wifi_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(("## Calling platform_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(struct platform_device *pdev, pm_message_t state)

{

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

#if (LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6,

defined(OOB_INTR_ONLY)

bcmsdh_oob_intr_set(0);

#endif

return 0;

}

static int wifi_resume(struct platform_device *pdev)

{

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

#if (LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6,

defined(OOB_INTR_ONLY)

if (dhd_os_check_if_up(bcmsdh_get_drvdata()))

39)) && 39)) && 71

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键和充电器连接的检测。

13 Android平台的Wifi模块移植要点

13.1 Wifi结构

Wifi模块全总结

蓝色部分是为了在android环境下，支持bcm43xx芯片需要修改的部分，各个部分的功能如下：

1. User interface（用户接口层）：控制和设置wifi的用户接口层

2. Android wifi service：它是android系统中的wifi服务部分，主要用来启动和停止wpa_supplicant，并作为用户接口层和wpa_supplicant交互的桥梁存在

3. Wpa_supplicant：支持wpa和wapi的外部库

4. Dhd driver：wifi模块的驱动

5. Dongle binary：BCM43xx的固件

6. BCM43xx：wifi的硬件芯片（是一个组合集成芯片）

13.2 Wifi模块环境

Wifi模块环境包括以下部分：

1. bcm43xx驱动源码

2. wpa_supplicant和支持WAPI的wapilib库

3. nvram.txt（BCM43xx芯片配置文件）

4. wpa_supplicant.conf和wifi固件

一般来说，第三和第四条件的文件在BCM43xx源码中都有包含。

13.3 Wifi模块的编译

13.3.1 Wifi驱动源码

这里不以某个类型的BCM43xx芯片和android版本作为特例来讲解wifi模块的编译过程，只是对编译的通用部分做简要的说明。

一般来说，wifi模块的编译可采用两种红方式：一是内部编译，二是模块编译。通常使用的是模块编译，这里也以模块编译wifi模块为例来说明wifi模块的编译过程。

在wifi模块驱动源码中，主要包含以下几个目录： Firmware：里面会提供对应BCM43xx芯片的固件

Config：提供wpa_supplicant.conf和nvram.txt以及dhcpcd.conf，还有android.mk文件。如果没有上面的配置文件，需要找到放入该目录。

Android.mk：这是一个文件，也是编译android平台编译wifi模块的入口 Src：wifi驱动的源码目录

其实，你看到的broadcom提供的驱动源码可能的组织方式跟上面是有差别的，但大致的内容差不多，上面只是针对模块源码中目录和文件的不同用途来说明的。

13.3.2 在android平台添加BCM43xx驱动

要在android平台编译wifi模块，首先要将wifi模块的源码添加到android平台下的目录中。至于添加到什么地方也不是固定的，一般会添加到vendor目录下的某个 75

目录下，下面我们把BCM43xx模块源码放在vendor/xxxx/wlan/bcm43xx下

（XXXXX代表产品名称）。要知道，在添加源码之前，这个bcm43xx目录是不存在的，需要手动创建，并在该目录下创建android和src两个目录： PC$ cd <ANDROID_ROOT>

PC$ mkdir ‐p vendor/xxxx/wlan/bcm4325/

PC$ cd vendor/xxxx/wlan/bcm4325/

PC$ mkdir android src

PC$ ls

android src

在创建好上面的目录后，就可以在目录下添加BCM43xx的相关源码了，src存放的是驱动源码，android目录下主要存放固件（即二级制镜像），编译文件（Android.mk），配置文件（nvram.txt和wpa_supplicant.conf）等。

添加好相关源码后，还需要做一定的修改工作（主要对编译文件的修改），不然模块无法被正常编译的，Android.mk的内容修改操作如下。 PC$ cp <WORK>/bcm4325_source/open‐src/src/dhd/android/config/Android.mk

<ANDROID_ROOT>/vendor/xxxx/wlan/bcm4325/android

PC$ cd <ANDROID_ROOT>/vendor/xxxx/wlan/bcm4325/android

PC$ vi Android.mk //到这里，找到Android.mk文件，文件内容如下 ……

# Install WLAN Driver, firmware, and configuration files.

local_target_dir := $(TARGET_OUT_ETC)/firmware

local_target_dir的路径，在后面会用到

########################

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := sdio-g-cdc-reclaim-idsup-wme-ccx-wapi.bin

LOCAL_MODULE_TAGS := user development

76 //这里定义

LOCAL_MODULE_CLASS := ETC

LOCAL_MODULE_PATH := $(local_target_dir)

LOCAL_SRC_FILES := $(LOCAL_MODULE)

include $(BUILD_PREBUILT)

########################

include $(CLEAR_VARS)

LOCAL_MODULE := nvram_4325b0.txt

LOCAL_MODULE_TAGS := user development

LOCAL_MODULE_CLASS := ETC

LOCAL_MODULE_PATH := $(local_target_dir)

LOCAL_SRC_FILES := $(LOCAL_MODULE)

include $(BUILD_PREBUILT)

########################

include $(CLEAR_VARS)

LOCAL_MODULE := dhd.ko

LOCAL_MODULE_TAGS := user development

LOCAL_MODULE_CLASS := ETC

LOCAL_MODULE_PATH := $(TARGET_OUT)/lib/modules LOCAL_SRC_FILES := $(LOCAL_MODULE)

include $(BUILD_PREBUILT)

########################

include $(CLEAR_VARS)

LOCAL_MODULE := wpa_supplicant.conf

LOCAL_MODULE_TAGS := user development

LOCAL_MODULE_CLASS := ETC

LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/wifi LOCAL_SRC_FILES := $(LOCAL_MODULE)

include $(BUILD_PREBUILT)

########################

include $(CLEAR_VARS)

LOCAL_MODULE := dhcpcd.conf

LOCAL_MODULE_TAGS := user development

LOCAL_MODULE_CLASS := ETC

LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/dhcpcd

LOCAL_SRC_FILES := android_dhcpcd.conf

include $(BUILD_PREBUILT)

########################

对上面的内容有必要说明一下：LOCAL_MODULE和LOCAL_MODULE _PATH的定义是这里需要修改的地方。对于LOCAL_MODULE_PATH的修改时一定的，但它主要依赖与android平台已经定义好的一些变量，如：TARGET_OUT _ETC和TARGET_OUT等。LOCAL_MODULE定义的是要操作的对象，也是前面提到的配置文件，编译好的驱动模块二进制文件和固件等。

该文件的作用：将各个文件拷贝到定义的地方，以供驱动模块和

wpa_supplicant等使用。、

对于驱动的源码，用户可以通过定制的wifi芯片管理函数来关闭和开启wifi模块，在dhd/sys/dhd_custom_gpio.c文件中有如下的函数定义： #define CUSTOMER_HW

#ifdef CUSTOMER_HW

extern void bcm_wlan_power_off(int);

BCM43xx BCM43xx Porting Guide for Android System

Broadcom Corporation Proprietary and Confidential

extern void bcm_wlan_power_on(int);

#endif /* CUSTOMER_HW */

所以用户可以使用自己定制的开关函数，或者使用BCM43xx自带的开关函数来控制wifi模块的开关。如果使用定制的开关函数，则需要在平台相关的代码中定义这两个函数：

Path：kernel/arch/arm/mach‐XXX/board‐XXXX.c

……

void bcm_wlan_power_off(int onoff);

void bcm_wlan_power_on(int onoff);

……

前面的Android.mk的修改中，有对dhd.ko的拷贝操作，这就是说源码编译后生成的模块二进制文件应该被暂时拷贝到Android.mk中指示的地方。这个暂时拷贝操作在驱动源码的编译文件dhd/linux/Makefile中被执行。 PC$ cd <ANDROID_ROOT>/vendor/xxxx/wlan/bcm4325/src

PC$ vi dhd/linux/Makefile +315

modules: $(OFILES)

test -r ./Makefile || ln –s $(SRCBASE)/dhd/linux/makefile.26 ./Makefile

$(MAKE) -C $(LINUXDIR) M=$(shell pwd) $(if $(VERBOSE),V=1) modules cp $(KMODULES) $(SRCBASE)/../android/.

下一步需要做的就是将wifi模块源码的顶层目录下的android.mk文件放到bcm43xx目录下，它是android编译入口文件，表示在编译android时，这个wifi驱动模块被包含到整个android编译系统中。它的内容如下：

PC$ cd <ANDROID_ROOT>/vendor/xxxx/wlan/bcm4325/

PC$ vim Android.mk

ifeq ($(BOARD_WLAN_DEVICE),bcm43xx)

include $(call all-subdir-makefiles)

endif

很简单，如果被BOARD_WLAN_DEVICE 被定义为bcm43xx，调用call all-subdir-makefiles函数来包含所有子目录下的Android.mk文件，这是android编译系统的规则。

那么，最后一步就是在相关的平台配置文件中定义BOARD_WLAN_DEVICE为bcm43xx，文件路径：vendor/XXXX/XXXX/BoardConfig.mk。

13.3.3 编译wifi驱动源码

在编译wifi驱动源码之前，首先要建立kernel环境，即要在编译wifi模块之前编译kernel，因为模块的编译时依赖与内核的。

内核的编译如下：

PC$ cd <ANDROID_ROOT>/kernel

PC$ make ARCH=arm CROSS_COMPILE=<ANDROID_ROOT>/prebuilt/ 79

linuxx86/toolchain/arm‐eabi‐4.4.0/bin/arm‐eabi‐ XXXX_defconfig

PC$ make ARCH=arm CROSS_COMPILE=<ANDROID_ROOT>/prebuilt/ linuxx86/toolchain/arm‐eabi‐4.4.0/bin/arm‐eabi‐ zImage

如果设置好了ARCH和CROSS_COMPILE的环境变量，就可以省略这两个选项的定义，直接使用make命令生成zImage了。

在编译好kernel之后，就可以进入bcm43xx源码目录dhd/linux下，这里面有两个文件Makefile和Makefile.26，如果没有Makefile文件就将Makfeile.26拷贝成Makfile文件（实际上是建立了一个符号链接文件），当然也要做前面的dhd.ko暂时拷贝命令的添加了。在该目录下输入如下命令编译模块源码： PC$ cd <ANDROID_ROOT>/vendor/xxxx/wlan/bcm4325/src

PC$ cd dhd/linux/

PC$ make ARCH=arm LINUXDIR=<ANDROID_ROOT>/kernel

CROSS_COMPILE=<ANDROID_ROOT>/prebuilt/linux

x86/toolchain/arm‐eabi‐

4.4.0/bin/arm‐eabi‐ dhd‐cdc‐sdmmc‐gpl

最后一条命令增加了一个命令选项LINUXDIR的传值，即告诉该编译文件kernel的所在位置，进入kernel的Makefile文件做设置工作，然后返回该目录下的Makefile文件进行编译工作。

到这里bcm43xx驱动源码已经编译完成，可以到android目录下查看有没有dhd.ko文件生成，如果有，即表明编译成功，否则查看编译过程的出错信息，解决错误问题再编译，直至编译成功。

13.3.4 在android中使用BCM43xx

前面的过程只是在android系统中添加编译了BCM43xx驱动源码，但是要想在android中使用它，还需要费一番功夫。需要修改的地方在开始的地方已经用蓝色背景标注了，在这里我们要看看到底要修改哪些文件。

13.3.4.1 hardware/libhardware_legacy/wifi/wifi.c ‐

为BCM43xx驱动模块做适当修改。Wifi.c作为加载wifi驱动模块和启动关闭wpa_supplicant的重要角色而存在，为了使wifi能更好的工作，该文件中的一些变量参数必须被适当的设置（根据wpa_supplicant.conf）。

PC$ vi hardware/libhardware_legacy/wifi/wifi.c

......

#define WIFI_DRIVER_MODULE_PATH

"/system/lib/modules/dhd.ko"

......

#define WIFI_DRIVER_MODULE_NAME "dhd"

......

#define WIFI_DRIVER_MODULE_ARG

"firmware_path=/etc/firmware/sdio-g-cdc-reclaim-idsup-wme-ccxwapi.

bin nvram_path=/etc/firmware/nvram_4325b0.txt"

......

#define WIFI_TEST_INTERFACE "eth0"

......

static const char IFACE_DIR[] = "";

......

static const char SUPP_CONFIG_TEMPLATE[]=

"/data/misc/wifi/wpa_supplicant.conf";

static const char SUPP_CONFIG_FILE[] =

"/etc/wifi/wpa_supplicant.conf";

......

上面的红色部分，就是对wifi驱动的特殊化定义，不同的wifi驱动会有不同的定义。修改还包括了固件的和配置文件的路径，以及接口名的相关定义。

WIFI_TEST_INTERFACE定义的是wpa_supplicant和UI的交互接口名，当通过property_get()函数获取wifi接口名错误时，就会使用此定义的接口名。Property_get()函数获取的接口名，就是init.xx.rc文件中的接口定义的wifi.interface：

Setprop wifi.interface “eth0”

SUPP_CONFIG_TEMPLATE定义的是wpa_supplicant配置文件的临时文 81

件。而SUPP_CONFIG_FILE定义的是wpa_supplicant运行时使用的配置文件，并且对wifi配置的修改也会保持到这个文件里。

IFACE_DIR是wpa_supplicant控制接口的目录，该目录下的接口被UI用来连接到wpa_supplicant，这个目录是由wpa_supplicant决定的，其实，这个接口实际上是一个socket，在wpa_supplicant启动时被创建，wpa_supplicant_ctrl_iface_init() 中有两种方式来创建这个socket接口：

（1）android系统的socket 它使用wpa_%ctrl_interface%组合来定义自己的名字，通过socket wpa_eth0 dgram ...命令来生成的（在init.rc中），如果使用这种socket，下面的代码中的接口名必须是一直的： ctrl_interface=eth0 (In wpa_supplicant.conf)

"socket wpa_eth0 ..." (In init.*.rc )

setprop wifi.interface "eth0" (In init.*.rc)

wpa_supplicant ‐ieth0 ... (In init.*.rc)

此时，IFACE_DIR的定义为NULL。（2）特殊socket Wpa_supplicant会通过wpa_supplicant.conf中的ctrl_interface目录来创建控制接口socket，而这个值一般被定义为："ctrl_interface=DIR=/data/misc/...."，这个socket的名字由wpa_supplicant的“-i”参数传递，如果使用这种方式的socket，下面的变量定义必须一致：

ctrl_interface=DIR=/data/misc/ (In wpa_supplicant.conf)

IFACE_DIR=/data/misc/ (In wifi.c)

13.3.4.2 kernel/arch/arm/mach‐XXX/board‐XXXX.c

为BCM43xx 驱动添加电源管理部分内容，这里不详细叙述。

13.3.4.3 system/core/rootdir/etc/init.xxx.rc

为支持BCM43xx驱动模块，修改wpa_supplicant服务。Init.xxx.rc文件的内容一般如下所示：

PC$ vi system/core/rootdir/etc/init.xxx.rc

...... //添加android系统接口

# to enable wifi

setprop wifi.interface "eth0"

# end of wifi

...... //修改wpa_supplicant.conf的权限

chmod 0660 /etc/wifi/wpa_supplicant.conf chown wifi wifi /etc/wifi/wpa_supplicant.conf

...... //wpa_supplicant服务的启动命令

service wpa_supplicant /system/bin/logwrapper

/system/bin/wpa_supplicant -Dwext -ieth0 -

c/etc/wifi/wpa_supplicant.conf

...... //给wpa_supplicant修改socket接口

socket wpa_eth0 dgram 660 wifi wifi

...... //修改dhcp接口

service dhcpcd /system/bin/dhcpcd -BKL eth0

......

13.3.4.4 vendor/XXXX/XXXX/BoardConfig.mk

为BCM43xx驱动添加配置变量。

PC$ vi vendor/XXXX/XXXX/BoardConfig.mk

……

ifneq ($(BUILD_TINY_ANDROID), true)

……

BOARD_WPA_SUPPLICANT_DRIVER := WEXT

BOARD_WLAN_DEVICE := bcm43xx

endif # !BUILD_TINY_ANDROID

……

对BCM43xx的WAPI的支持也需要做一系列的修改，这里不再对其进行详细的叙述了。

14 总结

最近一段时间里对wifi模块的学习，让我对wifi有了更多的了解，但这些也是不够的。对于wifi模块，需要了解的东西很多，这里只对其工作原理和工作流程以及移植过程进行了简单的阐述，还有很多方面没有概括到，如：协议层的实现方式和过程，以及数据传输中的细节和SDIO相关内容等等，这些在实际的wifi模块工作时可能都需要我们去进一步的分析和把握，虽然对wifi的理解可能不到位，但对这段时间学习做一次总结，也是大有裨益的，希望有机会可以更深入的学习wifi模块。

在wifi模块调试的过程中也会出现一系列的问题，这些问题可以归纳成不同的类型，对这些类型的问题做分析和总结，可以帮助我们在以后调试工作中快速定位问题所在。

对wifi的了解还远远不够，希望和wifi感兴趣的和已经成为高手的同仁能有更多的交流。

相关推荐

Wifi模块全总结

专栏推荐