1.1-kernel探索of读取过程1

探索kernel3.18设备树读取过程以及driver的match过程 1

---

正文

---

首先拿到机器的平台是MTK6750
先从platform开始分析，
先从LCM驱动入手，发现MTK已经封装了很多层上去了，最终追溯到mtkfb这样一个platform_driver上

然后无果
由于kernel才入门，所以对register等接口调用结构也是一点不了解，所以无果。

从of.h 分析，到platform.c的platform_match函数

通过dump_stack();打印堆栈里面的函数调用关系

幸好有code search这样的工具（OpenGrok search），能快速定位代码，虽然使用体验不好，将就用吧。

---

1. kernel3.18设备树的读取过程以及driver的match过程
   通过个人的阅读，match的过程分为6部分，
   (1)是设备树的内容，
   (2)是driver的内容，
   (3)是何时读取设备树内容的，
   (4)是何时调用driver内容的，
   (5)是何时进行匹配的，
   (6)是如何进行匹配的

(1).设备树的内容：
设备树的内容比较多，已经被很多书单独拿出来讲解了
所以参考链接：

(2).driver的内容：
我们暂时将mtkfb里面的内容为driver的内容，因为里面有真正去注册一个platform_driver，这个driver似乎和其他的driver不同（比如sensor的driver似乎不是platform_driver）
这里面有各种熟悉的probe，suspend，resume这种关键字，但和本主题最相关的应该是如何init，通过查看代码以及打印log证明register函数才是直接相关的

从log可以看出来
do_one_initcall是调用mtkfb_init的上一级，先mark一下，这一段至少可以看出是如何调用module_init的
但是本主题的关键不是这个，

(3).何时读取设备树的内容:
通过log可以发现至少是在platform_match()函数之前,在platform_match()函数里面发现了of_driver_match_device()函数，通过字面上的意思是设备树驱动匹配device，所以需要深入看一看。
通过对log的查看

trace_of_log_2.png

可以发现其中的“mediatek,MTKFB”match的时候是没有区分大小写的，所以追查下去是用了strcasecmp函数

trace_of_2.png

这是打印log的位置
发现node->properties->value和matches->compatible都写好了值，根据log在遍历node->properties->value可以看出来node->properties->value是读取的of，所以现在否定了of数值在platform_match()中读入，而应该是在操作node->properties->value为线索继续找。

现在验证一下是否是在platform_match()之前都将of信息读入了，所以在of_driver_match_device(dev, drv)函数的调用路径，虽然都是能调到base.c里面的of_device_id *__of_match_node(const struct of_device_id *matches, const struct device_node *node)
但重点是node->pro...->value的数值是多久写入的,所以要看一下代码调用流程，万一在函数里面读取的呢？所以可以直接打印一下value(经过尝试，发现value打印不出来，似乎遇到一点情况，还未知，正在看)~~

在base.c的__of_match_node函数里面，打印一下node->properties->value的数值，因为在platform_match()函数里面能打印出来drv->...->的name信息，但是打印不出来dev->...->value信息，所以需要查明到底是哪个时候给value赋值的，然后才能找出来是哪个时候读取of的

由于在dd.c中不能直接打印出来value，暂时就准备自己写打印函数来看能不能打印

实践证明是可以自己写调试函数的，所以以后会自己写调试函数，这样不至于到处打重复log而且还难搜索

由于一直遇到null pointer 导致重启，通过log发现只有少数固定value是null的，所以每次打印log的时候筛选了一下，避免访问null，当然对为什么node函数里面能过滤null指针感兴趣，但是这次目标不再这里，可以mark一下。
从log可以看出来，of数值早就加载到dev里面了，所以还需要继续追溯

---

之前是追溯到bus_for_each_dev,但我们能发现有一个函数和此函数特别像bus_for_each_drv，这里面的其他操作比如klist等

---

由于时间关系，这次暂时分析道这里，由于是粗略记录，没有详细的分析，所以后面会重新编辑这篇文章。