2． 设备树解析流程
2．1．内核启动并获取设备树
在uboot引导内核的时候，会将设备树在物理内存中的物理起始内存地址传递给Linux内核，然后Linux内核在unflattern＿device＿tree中解析设备镜像，并利用扫描到的信息创建由device node构成的链表，全局变量of＿allnodes指向链表的根节点，设备树的每一个节点都由一个struct device＿node与之对应。unflatten＿device＿tree的意思是解开设备树，在这个函数里调用了＿＿unflatten＿device＿tree这一函数：
＊
＊ ＿＿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
＊ ＠mynodes： 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））
所以，现在为止，我们得到了一个名为of＿allnodes的struct ＊device＿node，它指向了设备树展开后的device＿node树，后续的操作都是基于device＿node树。
2．2．创建platform＿device
内核从启动到创建设备的过程大致如下：在do＿initcalls中会传递level给do＿initcall＿level来调用不同层次的初始化函数，level的对应关系见linux－3．10／include／linux／init．h 第196行。在这个初始化过程中，会调用一个customize＿machine的函数。
2．3．Platform driver注册流程
此节分析Platform driver的注册流程，以memctrl驱动的注册为例分析。关于系统调用驱动初始化函数的流程分析，参考自动初始化机制章节。本章节分析从设备驱动文件的xxx＿init函数开始分析。
2．3．1． struct platform＿driver
platform＿driver是在device＿driver之上的一层封装，其结构如下：
struct platform＿driver ｛
int （＊probe）（struct platform＿device ＊）； 探测函数
int （＊remove）（struct platform＿device ＊）； 驱动卸载时执行
void （＊shutdown）（struct platform＿device ＊）； 关机时执行函数
int （＊suspend）（struct platform＿device ＊， pm＿message＿t state）； 挂起函数
int （＊resume）（struct platform＿device ＊）； 恢复函数
struct device＿driver driver； 管理的driver对象
const struct platform＿device＿id ＊id＿table； 匹配时使用
｝；
2．3．2． struct device＿driver
struct device＿driver是系统提供的基本驱动结构：
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； 自动创建的默认属性组
const struct dev＿pm＿ops ＊pm； 设备的功耗管理
struct driver＿private ＊p； 驱动的私有数据
｝；
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函数
drv－＞driver．probe ＝ platform＿drv＿probe； 里面实际调用的是drv的probe函数
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（）函数，它会向总线添加驱动：
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）
如果设备没有驱动，则为设备探测驱动，这个函数与注册设备调用的是同一个函数
driver＿probe＿device（drv， dev）；
device＿unlock（dev）；
if （dev－＞parent）
device＿unlock（dev－＞parent）；
return 0；
｝
driver＿probe＿device里调用really＿probe函数，并在really＿probe中调用驱动文件中的probe函数，对于memctrl驱动而言，就是xxxx＿memctrl＿probe函数。至此，platfprm driver就注册好了。
2．4．Platform Bus的匹配原则
由以上的代码分析得知，注册platform device时，会调用＿＿device＿attach －＞ driver＿match＿device，注册platform driver时，会调用＿＿driver＿attach －＞ driver＿match＿device，也就是说设备和驱动都会调用到这个函数：
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，这是驱动绑定的总线提供的匹配函数，这里注册的是platform总线设备，而platform总线的定义参考3．2．6 platform＿bus＿type。Platform对应的match函数为：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
根据驱动的of＿match＿table判断是否有驱动与之匹配。对memctrl驱动而言，其of＿match＿table如下：
static struct of＿device＿id xxxx＿memctrl＿of＿match［］ ＝ ｛
｛ ．compatible ＝ ＂xxxx，memctrl＂， ｝，
｛｝，
｝；
of＿driver＿match＿device的执行流程如下：
所以重点应该在＿＿of＿match＿node函数：
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］） 查找属性，检测节点的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函数，并且有且只有一个，其定义如下：
＊
＊ 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现在按照功能分组到单独的子部分。子部分内部的顺序由链接顺序决定。为了向后兼容，initcall（）将调用放到device init小节中。需要定义initcall（）的’id’参数，以便多个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的函数指针变量＿＿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段存储的初始化函数。比如对于模块来说level等于6。
4．2．动态加载的模块（．ko）4．2．1． Module＿init展开
如果设置为编译成动态加载的模块（．ko），module＿init的展开形式与编译到内核不一样。
Each module must use one module＿init（）．
＃define module＿init（initfn）
static inline initcall＿t ＿＿inittest（void） 检查定义的函数是否符合initcall＿t类型
｛ return initfn； ｝
int init＿module（void） ＿＿attribute＿＿（（alias（＃initfn）））；
alias属性是GCC的特有属性，将定义init＿module为函数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． 动态加载
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）该系统调用对应内核层的sys＿init＿module函数
路径：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数据结构
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＂）））
其作用是将作用的函数或数据放入指定的名为”section＿name”的段。
4．4． C语言宏定义中＃和＃＃的用法4．4．1． 一般用法
我们使用＃把宏参数变为一个字符串。
＃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 “，FORMAT，”” 五部分字符串，其中VALUE和FORMAT被宏参数的实际值替换了。
用＃＃把两个宏参数贴合在一起
＃define ADD＿TO＿SUM（sum＿number，val） sum＃＃sum＿bumber＋＝（val）
调用：ADD＿TO＿SUM（2，100）； －－＞ 打印：sum2＋＝（100）
需要注意的是凡宏定义里有用＇＃＇或＇＃＃＇的地方宏参数是不会再展开。
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＿＿）；
得到一个数值类型所对应的字符串缓冲大小＃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 －
