在寫linux 驅動中，使用dts/dtsi 會發現在填充 struct i2c_driver 與 struct platform_driver 是不一樣，
struct i2c_driver 需要id_match_table，同時需要id_table，而struct platform_driver 只要id_match_table，不需要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
└── i2c_device_match
├── acpi_driver_match_device
├── i2c_match_id
└── of_driver_match_device
└── of_match_device
└── of_match_node
└── __of_match_node
└── __of_device_is_compatible
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
所以，結論是:即使使用設備樹來匹配，也要對id_table進行有效的賦值，否則probe不會被回調!!!如果你也遇到了這個問題, 可以試試在驅動中定義一個空數組, 將其賦值給id_table