如果你也遇到了填充了 id_match_table,compitible 怎么看都一样,但 probe 就是不执行 (让我哭一会),你可以回头看一下上一篇的模板,我们这里虽然使用的是设备树匹配,但和 platform 的设备树匹配只填充 i2c_match_table 不同,i2c_driver 的设备树匹配需要同时填充 i2c_match_table 和 id_table 两个域,虽然后者是个空。如果你没有填充后面的成员,不妨试一下我的这种写法,我敢打赌你的 probe 也没有执行 ^-^。
问题是明确的,探索是漫长的,但是至少答案一定在源码中,也一定出在匹配的源码中,带着这样的思路,我从 "i2c_add_driver" 开始一路狂追,结论是使用设备树的话,只要 id_match_table,不需要 id_table!, 下面的 i2c_device_match 即可看出。
/home/jiang/Pictures/Selection_20170224_001.png
[Selection_20170224_001.png-6.4kB][1]
- //3.14.0/drivers/i2c/i2c-core.c
- 78 static int i2c_device_match(struct device * dev, struct device_driver * drv) 79 {
- 80 struct i2c_client * client = i2c_verify_client(dev);
- 81 struct i2c_driver * driver;
- 82 83
- if (!client) 84
- return 0;
- 85 86
- /* Attempt an OF style match */
- 87
- if (of_driver_match_device(dev, drv)) 88
- return 1;
- 89 90
- /* Then ACPI style match */
- 91
- if (acpi_driver_match_device(dev, drv)) 92
- return 1;
- 93 94 driver = to_i2c_driver(drv);
- 95
- /* match on an id table if there is one */
- 96
- if (driver - >id_table) 97
- return i2c_match_id(driver - >id_table, client) != NULL;
- 98 99
- return 0;
- 100
- }
从 i2c_device_match 的定义可以看出, 和 platform 总线一样, i2c 的 match 函数也是优先选择设备树, 如果设备树已经匹配了, 函数就会返回, 不会再最平台文件的设备信息进行判断, 即不会理会 id_table 的值, 确保匹配是一定不需要 id_table 了,而事实上 probe 确实没有执行,那么问题就可能出现在 probe 的回调过程了,和所有的总线设备一样,回调 probe 的过程始于 driver_match_id,于是又是一路狂追,终于在 i2c_device_probe() 中找到了我臆想中的对 id_table 的检测
下面是我追的源码树,大家可以验证一下
所以,结论是: 即使使用设备树来匹配,也要对 id_table 进行有效的赋值,否则 probe 不会被回调!!! 如果你也遇到了这个问题, 可以试试在驱动中定义一个空数组, 将其赋值给 id_table^-^
来源: http://www.cnblogs.com/xiaojiang1025/p/6501956.html