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等


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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,911评论 5 460
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,014评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 142,129评论 0 320
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,283评论 1 264
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,159评论 4 357
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,161评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,565评论 3 382
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,251评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,531评论 1 292
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,619评论 2 310
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,383评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,255评论 3 313
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,624评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,916评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,199评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,553评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,756评论 2 335

推荐阅读更多精彩内容