Linux i2c子系统(三)(2)

/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的检测

下面是我追的源码树，大家可以验证一下

i2c_add_driver()
        └── i2c_register_driver
                └── driver_register
                        ├── driver_find
                        │  ├── kset_find_obj
                        │  ├── kobject_put
                        │  └── to_driver
                        └── bus_add_driver
                                └── driver_attach
                                        └── bus_for_each_dev
                                                ├── next_device
                                                └── __driver_attach
                                                        ├── driver_match_device
                                                        └── driver_probe_device
                                                                └── really_probe
                                                                        └── i2c_device_probe
                                                                                └── i2c_match_id