2． 設備樹解析流程

 2．1．內核啟動并獲取設備樹

在uboot引導內核的時候，會將設備樹在物理內存中的物理起始內存地址傳遞給Linux內核，然后Linux內核在unflattern＿device＿tree中解析設備鏡像，并利用掃描到的信息創(chuàng)建由device node構成的鏈表，全局變量of＿allnodes指向鏈表的根節(jié)點，設備樹的每一個節(jié)點都由一個struct device＿node與之對應。unflatten＿device＿tree的意思是解開設備樹，在這個函數(shù)里調用了＿＿unflatten＿device＿tree這一函數(shù)：

＊
＊ ＿＿unflatten＿device＿tree － create tree of device＿nodes from flat blob
＊
＊ unflattens a device－tree， creating the
＊ tree of struct device＿node． It also fills the ＂name＂ and ＂type＂
＊ pointers of the nodes so the normal device－tree walking functions
＊ can be used．
＊ ＠blob： The blob to expand
＊ ＠m(xù)ynodes： The device＿node tree created by the call
＊ ＠dt＿alloc： An allocator that provides a virtual address to memory
＊ for the resulting tree

static void ＿＿unflatten＿device＿tree（struct boot＿param＿header ＊blob，
       struct device＿node ＊＊mynodes，
       void ＊ （＊dt＿alloc）（u64 size， u64 align））

所以，現(xiàn)在為止，我們得到了一個名為of＿allnodes的struct ＊device＿node，它指向了設備樹展開后的device＿node樹，后續(xù)的操作都是基于device＿node樹。

2．2．創(chuàng)建platform＿device

內核從啟動到創(chuàng)建設備的過程大致如下：在do＿initcalls中會傳遞level給do＿initcall＿level來調用不同層次的初始化函數(shù)，level的對應關系見linux－3．10／include／linux／init．h 第196行。在這個初始化過程中，會調用一個customize＿machine的函數(shù)。

2．3．Platform driver注冊流程

此節(jié)分析Platform driver的注冊流程，以memctrl驅動的注冊為例分析。關于系統(tǒng)調用驅動初始化函數(shù)的流程分析，參考自動初始化機制章節(jié)。本章節(jié)分析從設備驅動文件的xxx＿init函數(shù)開始分析。

2．3．1． struct platform＿driver

platform＿driver是在device＿driver之上的一層封裝，其結構如下：

struct platform＿driver ｛
int （＊probe）（struct platform＿device ＊）；   探測函數(shù)
int （＊remove）（struct platform＿device ＊）；  驅動卸載時執(zhí)行
void （＊shutdown）（struct platform＿device ＊）；  關機時執(zhí)行函數(shù)
int （＊suspend）（struct platform＿device ＊， pm＿message＿t state）；  掛起函數(shù)
int （＊resume）（struct platform＿device ＊）；     恢復函數(shù)
struct device＿driver driver；           管理的driver對象
const struct platform＿device＿id ＊id＿table；   匹配時使用
｝；

2．3．2． struct device＿driver

struct device＿driver是系統(tǒng)提供的基本驅動結構：

struct device＿driver ｛
const char   ＊name；  驅動名稱
struct bus＿type   ＊bus； 所屬總線
struct module   ＊owner； 模塊擁有者
const char   ＊mod＿name； 內建的模塊使用
bool suppress＿bind＿attrs；  是否綁定到sysfs
const struct of＿device＿id  ＊of＿match＿table； 設備樹匹配表
const struct acpi＿device＿id  ＊acpi＿match＿table； ACPI匹配表
int （＊probe） （struct device ＊dev）；  探測設備
int （＊remove） （struct device ＊dev）； 與設備脫離時調用
void （＊shutdown） （struct device ＊dev）； 在關機時關閉設備
int （＊suspend） （struct device ＊dev， pm＿message＿t state）； 使設備進入睡眠模式調用
int （＊resume） （struct device ＊dev）；  喚醒設備時調用
const struct attribute＿group ＊＊groups； 自動創(chuàng)建的默認屬性組
const struct dev＿pm＿ops ＊pm；  設備的功耗管理
struct driver＿private ＊p； 驅動的私有數(shù)據(jù)
｝；

2．3．3． platform＿driver＿register

Platform＿driver的注冊接口是platform＿driver＿register，其定義如下：

int platform＿driver＿register（struct platform＿driver ＊drv）
｛
drv－＞driver．bus ＝ ＆platform＿bus＿type；  設置總線類型
if （drv－＞probe）    確認定義了probe函數(shù)    
 drv－＞driver．probe ＝ platform＿drv＿probe；  里面實際調用的是drv的probe函數(shù)
if （drv－＞remove）
 drv－＞driver．remove ＝ platform＿drv＿remove；
if （drv－＞shutdown）
 drv－＞driver．shutdown ＝ platform＿drv＿shutdown；
return driver＿register（＆drv－＞driver）；
｝

platform＿driver＿register接口是為注冊總線驅動做一些準備工作，定義了總線類型，設置了driver的部分接口，最后driver＿register會向總線注冊驅動

2．3．4． driver＿registerint driver＿register（struct device＿driver ＊drv）
｛
int ret；
struct device＿driver ＊other；
BUG＿ON（！drv－＞bus－＞p）；
if （（drv－＞bus－＞probe ＆＆ drv－＞probe） ｜｜
    （drv－＞bus－＞remove ＆＆ drv－＞remove） ｜｜
    （drv－＞bus－＞shutdown ＆＆ drv－＞shutdown））
 printk（KERN＿WARNING ＂Driver ＇％s＇ needs updating － please use ＂
  ＂bus＿type methods＂， drv－＞name）；
other ＝ driver＿find（drv－＞name， drv－＞bus）； 檢查驅動是否已經注冊
if （other） ｛
 printk（KERN＿ERR ＂Error： Driver ＇％s＇ is already registered， ＂
  ＂aborting．．．＂， drv－＞name）；
 return －EBUSY；
｝
ret ＝ bus＿add＿driver（drv）；   driver＿register的主要工作放在了這里
if （ret）
 return ret；
ret ＝ driver＿add＿groups（drv， drv－＞groups）； 主要是在sysfs添加驅動屬性
if （ret） ｛
 bus＿remove＿driver（drv）；
 return ret；
｝
kobject＿uevent（＆drv－＞p－＞kobj， KOBJ＿ADD）；   涉及到uevent，暫時不分析
return ret；
｝

2．3．5． bus＿add＿driver

由以上分析可知，驅動的注冊，重點在bus＿add＿driver（）函數(shù)，它會向總線添加驅動：

Drivers／base／bus．c
int bus＿add＿driver（struct device＿driver ＊drv）
｛
struct bus＿type ＊bus；
struct driver＿private ＊priv；  包含與驅動相關的kobject和klist結構
int error ＝ 0；
bus ＝ bus＿get（drv－＞bus）；  獲取設備所屬的總線類型
if （！bus）
 return －EINVAL；
pr＿debug（＂bus： ＇％s＇： add driver ％s＂， bus－＞name， drv－＞name）；
priv ＝ kzalloc（sizeof（＊priv）， GFP＿KERNEL）；
if （！priv） ｛
 error ＝ －ENOMEM；
 goto out＿put＿bus；
｝
klist＿init（＆priv－＞klist＿devices， NULL， NULL）；
priv－＞driver ＝ drv；
drv－＞p ＝ priv；
priv－＞kobj．kset ＝ bus－＞p－＞drivers＿kset；
error ＝ kobject＿init＿and＿add（＆priv－＞kobj， ＆driver＿ktype， NULL，
        ＂％s＂， drv－＞name）；
if （error）
 goto out＿unregister；
klist＿add＿tail（＆priv－＞knode＿bus， ＆bus－＞p－＞klist＿drivers）；
if （drv－＞bus－＞p－＞drivers＿autoprobe） ｛ 如果設置了自動探測
 error ＝ driver＿attach（drv）；
 if （error）
  goto out＿unregister；
｝
module＿add＿driver（drv－＞owner， drv）；
error ＝ driver＿create＿file（drv， ＆driver＿attr＿uevent）；
if （error） ｛
 printk（KERN＿ERR ＂％s： uevent attr （％s） failed＂，
  ＿＿func＿＿， drv－＞name）；
｝
error ＝ driver＿add＿attrs（bus， drv）；
if （error） ｛
  How the hell do we get out of this pickle？ Give up
 printk（KERN＿ERR ＂％s： driver＿add＿attrs（％s） failed＂，
  ＿＿func＿＿， drv－＞name）；
｝
if （！drv－＞suppress＿bind＿attrs） ｛
 error ＝ add＿bind＿files（drv）；
 if （error） ｛
   Ditto
  printk（KERN＿ERR ＂％s： add＿bind＿files（％s） failed＂，
   ＿＿func＿＿， drv－＞name）；
 ｝
｝
return 0；
out＿unregister：
kobject＿put（＆priv－＞kobj）；
kfree（drv－＞p）；
drv－＞p ＝ NULL；
out＿put＿bus：
bus＿put（bus）；
return error；
｝
2．3．6． driver＿attach

driver＿attach會嘗試綁定設備和驅動。編譯總線上的所有設備，然驅動挨個嘗試匹配，如果driver＿probe＿device（）返回0且＠dev－＞driver被設置，就代表找到了一對兼容的設備驅動。

int driver＿attach（struct device＿driver ＊drv）
｛
return bus＿for＿each＿dev（drv－＞bus， NULL， drv， ＿＿driver＿attach）；
｝
EXPORT＿SYMBOL＿GPL（driver＿attach）；
2．3．7． ＿＿driver＿attach

對于每一個總線的設備，driver＿attach都會調用＿＿driver＿attach來嘗試與驅動匹配。

static int ＿＿driver＿attach（struct device ＊dev， void ＊data）
｛
struct device＿driver ＊drv ＝ data；

 ＊ Lock device and try to bind to it． We drop the error
 ＊ here and always return 0， because we need to keep trying
 ＊ to bind to devices and some drivers will return an error
 ＊ simply if it didn＇t support the device．
 ＊
 ＊ driver＿probe＿device（） will spit a warning if there
 ＊ is an error．
 
if （！driver＿match＿device（drv， dev））  匹配設備和驅動，這里調用的是platform＿match
 return 0；
if （dev－＞parent）  Needed for USB
 device＿lock（dev－＞parent）；
device＿lock（dev）；  設置互斥鎖，防止其他進程訪問設備資源
if （！dev－＞driver）  
如果設備沒有驅動，則為設備探測驅動，這個函數(shù)與注冊設備調用的是同一個函數(shù)
 driver＿probe＿device（drv， dev）；  
device＿unlock（dev）；
if （dev－＞parent）
 device＿unlock（dev－＞parent）；
return 0；
｝

driver＿probe＿device里調用really＿probe函數(shù)，并在really＿probe中調用驅動文件中的probe函數(shù)，對于memctrl驅動而言，就是xxxx＿memctrl＿probe函數(shù)。至此，platfprm driver就注冊好了。

2．4．Platform Bus的匹配原則

由以上的代碼分析得知，注冊platform device時，會調用＿＿device＿attach －＞ driver＿match＿device，注冊platform driver時，會調用＿＿driver＿attach －＞ driver＿match＿device，也就是說設備和驅動都會調用到這個函數(shù)：

static inline int driver＿match＿device（struct device＿driver ＊drv，
         struct device ＊dev）
｛
return drv－＞bus－＞match ？ drv－＞bus－＞match（dev， drv） ： 1；
｝

drv－＞bus－＞match，這是驅動綁定的總線提供的匹配函數(shù)，這里注冊的是platform總線設備，而platform總線的定義參考3．2．6 platform＿bus＿type。Platform對應的match函數(shù)為：platform＿match：

static int platform＿match（struct device ＊dev， struct device＿driver ＊drv）
｛
struct platform＿device ＊pdev ＝ to＿platform＿device（dev）；
struct platform＿driver ＊pdrv ＝ to＿platform＿driver（drv）；
 Attempt an OF style match first
if （of＿driver＿match＿device（dev， drv））
 return 1；
 Then try ACPI style match
if （acpi＿driver＿match＿device（dev， drv））
 return 1；
 Then try to match against the id table
if （pdrv－＞id＿table）
 return platform＿match＿id（pdrv－＞id＿table， pdev） ！＝ NULL；
 fall－back to driver name match
return （strcmp（pdev－＞name， drv－＞name） ＝＝ 0）；
｝
2．4．1． of＿driver＿match＿device

根據(jù)驅動的of＿match＿table判斷是否有驅動與之匹配。對memctrl驅動而言，其of＿match＿table如下：

static struct of＿device＿id xxxx＿memctrl＿of＿match［］ ＝ ｛
｛ ．compatible ＝ ＂xxxx，memctrl＂， ｝，
  ｛｝，
｝；

of＿driver＿match＿device的執(zhí)行流程如下：

所以重點應該在＿＿of＿match＿node函數(shù)：

2．4．1．1． ＿＿of＿match＿nodestatic const struct of＿device＿id ＊＿＿of＿match＿node（const struct of＿device＿id ＊matches， const struct device＿node ＊node）
｛
if （！matches）
 return NULL；
while （matches－＞name［0］ ｜｜ matches－＞type［0］ ｜｜ matches－＞compatible［0］） ｛
 int match ＝ 1；
 if （matches－＞name［0］）   查找名字
      match ＆＝ node－＞name ＆＆ ！strcmp（matches－＞name， node－＞name）；
 if （matches－＞type［0］）   查找類型
      match ＆＝ node－＞type ＆＆ ！strcmp（matches－＞type， node－＞type）；
 if （matches－＞compatible［0］）  查找屬性，檢測節(jié)點的compatible是否與驅動的一致
      match ＆＝ ＿＿of＿device＿is＿compatible（node， matches－＞compatible）；
 if （match）
      return matches；
     matches＋＋；
｝
return NULL；
｝

3． 使用設備資源  

4． 自動初始化機制 

4．1．編譯到內核

4．1．1． module＿init宏展開

Linux中每一個模塊都有一個module＿init函數(shù)，并且有且只有一個，其定義如下：

＊
＊ module＿init（） － driver initialization entry point
＊ ＠x： function to be run at kernel boot time or module insertion
＊
＊ module＿init（） will either be called during do＿initcalls（） （if
＊ builtin） or at module insertion time （if a module）．  There can only
＊ be one per module．

＃define module＿init（x） ＿＿initcall（x）；
＿＿initcall（x）定義如下：
＃define ＿＿initcall（fn） device＿initcall（fn）

device＿initcall（fn）定義如下：

＃define device＿initcall（fn）       ＿＿define＿initcall（fn， 6）

＿＿define＿initcall的定義如下：

initcalls are now grouped by functionality into separate
＊ subsections． Ordering inside the subsections is determined
＊ by link order．
＊ For backwards compatibility， initcall（） puts the call in
＊ the device init subsection．
＊
＊ The ｀id＇ arg to ＿＿define＿initcall（） is needed so that multiple initcalls
＊ can point at the same handler without causing duplicate－symbol build errors．


＃define ＿＿define＿initcall（fn， id）
static initcall＿t ＿＿initcall＿＃＃fn＃＃id ＿＿used
＿＿attribute＿＿（（＿＿section＿＿（＂．initcall＂ ＃id ＂．init＂））） ＝ fn

Initcalls現(xiàn)在按照功能分組到單獨的子部分。子部分內部的順序由鏈接順序決定。為了向后兼容，initcall（）將調用放到device init小節(jié)中。需要定義initcall（）的’id’參數(shù)，以便多個initcall可以指向同一個處理程序，而不會導致重復符號構建錯誤。若不理解上述代碼的用法，可以參考＿＿attribute＿＿的section用法和C語言宏定義中＃和＃＃的用法。所以將＿＿define＿initcall展開將會是下面的內容：

假設＿＿define＿initcall（led＿init， 6）
Static initcall＿t ＿＿initcall＿led＿init6 ＿＿used
＿＿attribute＿＿（（＿＿section＿＿（＂．initcall6．init＂））） ＝ led＿init

即是定義了一個類型為initcall＿t的函數(shù)指針變量＿＿initcall＿led＿init6，并賦值為led＿init，該變量在鏈接時會鏈接到section（．initcall6．init）。

4．1．2． 鏈接腳本

在linux3．10／arch／arm／kernel／vmlinux．lds．S中：

．．．．．．
SECTIONS   line 54
｛
．．．．．．
．init．data ： ｛  line 202
＃ifndef CONFIG＿XIP＿KERNEL
 INIT＿DATA
＃endif
 INIT＿SETUP（16）
 INIT＿CALLS
 CON＿INITCALL
 SECURITY＿INITCALL
 INIT＿RAM＿FS
｝
．．．．．．
｝

在linux3．10／include／asm－generic／vmlinux．lds．h中：

＃define VMLINUX＿SYMBOL（x） ＿＿VMLINUX＿SYMBOL（x）
＃define ＿＿VMLINUX＿SYMBOL（x） x
．．．．．．  line 664
＃define INIT＿CALLS＿LEVEL（level）      
 VMLINUX＿SYMBOL（＿＿initcall＃＃level＃＃＿start） ＝ ．；  
 ＊（．initcall＃＃level＃＃．init）    
 ＊（．initcall＃＃level＃＃s．init）    
＃define INIT＿CALLS      
 VMLINUX＿SYMBOL（＿＿initcall＿start） ＝ ．；  
 ＊（．initcallearly．init）    
 INIT＿CALLS＿LEVEL（0）    
 INIT＿CALLS＿LEVEL（1）    
 INIT＿CALLS＿LEVEL（2）    
 INIT＿CALLS＿LEVEL（3）    
 INIT＿CALLS＿LEVEL（4）    
 INIT＿CALLS＿LEVEL（5）    
 INIT＿CALLS＿LEVEL（rootfs）    
 INIT＿CALLS＿LEVEL（6）    
 INIT＿CALLS＿LEVEL（7）    
 VMLINUX＿SYMBOL（＿＿initcall＿end） ＝ ．；
．．．．．．

所以 INIT＿CALLS＿LEVEL（6）會展開為：

＿＿initcall6＿start ＝ ．；  ＊（．initcall6．init）   ＊（．initcall6s．init）

所以＿＿initcall＿led＿init6會鏈接到

section（．initcall6．init）
4．1．3． 初始化

內核啟動流程為：

do＿initcall＿level的主要內容如下：

linux3．10／init／main．c line 744
static void ＿＿init do＿initcall＿level（int level）
｛
．．．．．
for （fn ＝ initcall＿levels［level］； fn ＜ initcall＿levels［level＋1］； fn＋＋）
         do＿one＿initcall（＊fn）；
｝

由代碼可知，內核會依次調用level段存儲的初始化函數(shù)。比如對于模塊來說level等于6。

4．2．動態(tài)加載的模塊（．ko）4．2．1． Module＿init展開

如果設置為編譯成動態(tài)加載的模塊（．ko），module＿init的展開形式與編譯到內核不一樣。

Each module must use one module＿init（）．
＃define module＿init（initfn）    
static inline initcall＿t ＿＿inittest（void）     檢查定義的函數(shù)是否符合initcall＿t類型
｛ return initfn； ｝    
int init＿module（void） ＿＿attribute＿＿（（alias（＃initfn）））；

alias屬性是GCC的特有屬性，將定義init＿module為函數(shù)initfn的別名，所以module＿init（initfn）的作用就是定義一個變量名 init＿module，其地址和initfn是一樣的。

4．2．2． ＊mod．c文件

編譯成module的模塊都會自動產生一個＊．mod．c的文件，例如：

struct module ＿＿this＿module
＿＿attribute＿＿（（section（＂．gnu．linkonce．this＿module＂））） ＝ ｛
．name ＝ KBUILD＿MODNAME，
．init ＝ init＿module，
＃ifdef CONFIG＿MODULE＿UNLOAD
．exit ＝ cleanup＿module，
＃endif
．arch ＝ MODULE＿ARCH＿INIT，
｝；

即定義了一個類型為module的全局變量＿＿this＿module，其成員．init就是上文由module＿init定義的init＿module變量。并且＿＿this＿module會被鏈接到section（＂．gnu．linkonce．this＿module＂）。

4．2．3． 動態(tài)加載

insmod是busybox提供的用戶層命令：路徑busybox／modutils／ insmod．c

insmod＿main
bb＿init＿module
init＿module

路徑busybox／modutils／modutils．c：

＃define init＿module（mod， len， opts） ．
syscall（＿＿NR＿init＿module， mod， len， opts）該系統(tǒng)調用對應內核層的sys＿init＿module函數(shù)

路徑：kernel／module．c

SYSCALL＿DEFINE3（init＿module，…）
／／加載模塊的ko文件，并解釋各個section，重定位
mod ＝ load＿module（umod， len， uargs）；
／／查找section（＂．gnu．linkonce．this＿module＂）
modindex ＝ find＿sec（hdr， sechdrs， secstrings，＂．gnu．linkonce．this＿module＂）；
／／找到Hello＿module．mod．c定義的module數(shù)據(jù)結構
mod ＝ （void ＊）sechdrs［modindex］．sh＿addr；
if （mod－＞init ！＝ NULL）
ret ＝ do＿one＿initcall（mod－＞init）； ／／調用initfn．
4．3．＿＿attribute＿＿的section用法

＿＿define＿initcall使用了gcc的 ＿＿attribute＿＿眾多屬性中的section子項，其使用方式為：

＿＿attribute＿＿（（＿＿section＿＿（＂section＿name＂）））

其作用是將作用的函數(shù)或數(shù)據(jù)放入指定的名為”section＿name”的段。

4．4． C語言宏定義中＃和＃＃的用法4．4．1． 一般用法

我們使用＃把宏參數(shù)變?yōu)橐粋�字符串。

＃define PRINT（FORMAT，VALUE）
printf（＂The value of＂＃VALUE＂is ＂ FORMAT＂＂，VALUE）

調用：printf（＂％d＂，x＋3）；     －－＞     打印：The value of x＋3 is 20

這是因為”The value of”＃VALUE”is ” FORMAT””實際上是包含了”The value of “，＃VALUE，”is “，F(xiàn)ORMAT，”” 五部分字符串，其中VALUE和FORMAT被宏參數(shù)的實際值替換了。

用＃＃把兩個宏參數(shù)貼合在一起

＃define ADD＿TO＿SUM（sum＿number，val） sum＃＃sum＿bumber＋＝（val）

調用：ADD＿TO＿SUM（2，100）；     －－＞     打印：sum2＋＝（100）

需要注意的是凡宏定義里有用＇＃＇或＇＃＃＇的地方宏參數(shù)是不會再展開。

4．4．2． ＇＃＇和＇＃＃＇的一些應用特例合并匿名變量名＃define  ＿＿＿ANONYMOUS1（type， var， line）  type  var＃＃line
＃define  ＿＿ANONYMOUS0（type， line）  ＿＿＿ANONYMOUS1（type， ＿anonymous， line）
＃define  ANONYMOUS（type）  ＿＿ANONYMOUS0（type， ＿＿LINE＿＿）

例：ANONYMOUS（static int）；  即 static int ＿anonymous70；  70表示該行行號；第一層：ANONYMOUS（static int）； －－＞  ＿＿ANONYMOUS0（static int， LINE）；第二層：                           －－＞  ＿＿＿ANONYMOUS1（static int， ＿anonymous， 70）；第三層：                           －－＞  static int  ＿anonymous70；即每次只能解開當前層的宏，所以＿＿LINE＿＿在第二層才能被解開；

填充結構＃define  FILL（a）   ｛a， ＃a｝
enum IDD｛OPEN， CLOSE｝；
typedef struct MSG｛
 IDD id；
 const char  msg；
｝MSG；
MSG ＿msg［］ ＝ ｛FILL（OPEN）， FILL（CLOSE）｝；

相當于：

MSG ＿msg［］ ＝ ｛｛OPEN， OPEN｝，
             ｛CLOSE， CLOSE｝｝；
記錄文件名＃define  ＿GET＿FILE＿NAME（f）   ＃f
＃define  GET＿FILE＿NAME（f）    ＿GET＿FILE＿NAME（f）
static char  FILE＿NAME［］ ＝ GET＿FILE＿NAME（＿＿FILE＿＿）；
得到一個數(shù)值類型所對應的字符串緩沖大小＃define  ＿TYPE＿BUF＿SIZE（type）  sizeof ＃type
＃define  TYPE＿BUF＿SIZE（type）   ＿TYPE＿BUF＿SIZE（type）
char  buf［TYPE＿BUF＿SIZE（INT＿MAX）］；
    －－  char  buf［＿TYPE＿BUF＿SIZE（0x7fffffff）］；
    －－  char  buf［sizeof 0x7fffffff］；

這里相當于：

char  buf［11］；
－ END －