驅(qū)動注冊的probe函數(shù)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上驅(qū)動注冊的probe函數(shù)probe函數(shù)在設(shè)備驅(qū)動注冊最后收尾工作，當(dāng)設(shè)備的device 和其對應(yīng)的driver 在總線上完成配對之后，系統(tǒng)就調(diào)用設(shè)備的probe函數(shù)完成驅(qū)動注冊最后工作。資源、調(diào)用函數(shù)以及其他相關(guān)工作。下面是probe被調(diào)用的一些程序流程。從driver_register看起：cpp 1. int driver_register(struct device_driver * drv)  2.   3.     klist_i

2、nit(&drv->klist_devices, klist_devices_get, klist_devices_put);  4.     init_completion(&drv->unloaded);  5.     return bus_add_driver(drv);  6.   klist_init與init_completion沒去管它，可能是2.6的這個設(shè)備模型

3、要做的一些工作。直覺告訴我要去bus_add_driver。bus_add_driver中：都是些Kobject 與 klist 、attr等。還是與設(shè)備模型有關(guān)的。但是其中有一句：driver_attach(drv);單聽名字就很像：cpp 1. void driver_attach(struct device_driver * drv)  2.   3.     bus_for_each_dev(drv->bus, NULL, drv,

4、 _driver_attach);  4.   這個熟悉，遍歷總線上的設(shè)備并設(shè)用_driver_attach。在_driver_attach中又主要是這樣：driver_probe_device(drv, dev);跑到driver_probe_device中去看看：有一段很重要：if (drv->bus->match && !drv->bus->match(dev, drv)goto Done;明顯，是調(diào)用的驅(qū)動的總線上的match函數(shù)。如果返回1，則可以繼續(xù)，否則就Done了。繼承執(zhí)行的話：cpp&#

5、160;1. if (drv->probe)  2.     ret = drv->probe(dev);  3. if (ret)   4.     dev->driver = NULL;  5.     goto ProbeFailed;  6.   只要p

6、robe存在則調(diào)用之。至此就完成了probe的調(diào)用。這個過程鏈的關(guān)鍵還是在drv->bus->match ，因?yàn)槠溆嗟牡胤匠鲥e的話就是注冊失敗，而只要注冊不失敗且match返回1，那么就鐵定會調(diào)用驅(qū)程的probe了。你可以注冊一個總線類型和總線,并在 match中總是返回 1, 會發(fā)現(xiàn),只要struct device_driver中的bus類型正確時,probe函數(shù)總是被調(diào)用.有兩個重要的鏈表掛在bus上，一個是設(shè)備device鏈表，一個是驅(qū)動driver鏈表。每當(dāng)我們向一根bus注冊一個驅(qū)動driver時，套路是這樣的：driver_register(struct device_

7、driver * drv) -> bus_add_driver() -> driver_attach() ->bus_for_each_dev(drv->bus, NULL, drv, _driver_attach);bus_for_each_dev遍歷該總線上所有的device，執(zhí)行一次_driver_attach()，看能不能將驅(qū)動關(guān)聯(lián)(attach)到某個設(shè)備上去。_driver_attach()->driver_probe_device()->drv->bus->match(dev, drv), / 調(diào)用bus的match函數(shù)，看devi

8、ce和driver匹不匹配。如果匹配上，繼續(xù)執(zhí)行really_probe()。->really_probe()->driver->probe()。(如果bus->probe非空，則調(diào)用bus->probe)而每當(dāng)我們向一根bus添加一個硬件時時，套路是這樣的：device_add() device_add 中有很多操作kobject，注冊sysfs，形成硬件hiberarchy結(jié)構(gòu)的代碼。如果您忘記了，先回頭去參考參考"我是sysfs"->bus_attach_device() -> device_attach() ->bus

9、_for_each_drv()bus_for_each_drv與bus_for_each_dev類似，遍歷該總線上所有的driver，執(zhí)行一次_device_attach()，看能不能將設(shè)備關(guān)聯(lián)(attach)到某個已登記的驅(qū)動上去。_device_attach()->driver_probe_device() /后面與上面一樣總結(jié)一些，一句話，注冊一個某個bus的驅(qū)動就是先把驅(qū)動自己鏈入到bus驅(qū)動鏈表中去，在從bus的設(shè)備鏈表中一一尋找，看有沒有自己可以關(guān)聯(lián)上的設(shè)備。找到就probe，再把二者bind起來。反之，添加設(shè)備道理也是一樣的。論壇討論帖：1. 在看platform驅(qū)動是，發(fā)

10、現(xiàn)一個很低能的問題，static int _devinitdm9000_probe(struct platform_device *pdev) 中的struct platform_device *pdev是從那里來的device，跟蹤platform_driver_register(&dm9000_driver);一直沒有發(fā)現(xiàn)platform_device的出現(xiàn)，但是現(xiàn)在probe函數(shù)中突然出現(xiàn)了這個變量，那么這個變量是從和而來？2. platform驅(qū)動分為platform_driver和platform_device兩個結(jié)構(gòu)體表示，前者表示平臺驅(qū)動，后者表示平臺設(shè)備，這個struc

11、t platform_device *pdev就是在平臺相關(guān)文件里注冊的。平臺下會定義一個platform_device,然后platform_device_register(&platform_device)，所以你注冊的平臺驅(qū)動，當(dāng)在platform_bus上探測到有個設(shè)備的時候，這個你之前在平臺文件里注冊的platform_device就會傳過來。3. "platform_bus上探測到有個設(shè)備的時候"此句怎么理解,是怎么探測到的呢?4. 驅(qū)動肯定是自己注冊了。至于設(shè)備的注冊，有些設(shè)備所使用的協(xié)議有枚舉過程，從這處過程中可以得到設(shè)備信息，進(jìn)而生成相應(yīng)設(shè)備結(jié)構(gòu)體

12、，然后注冊在相應(yīng)總線上。在總線上注冊設(shè)備時，會遍歷該總線上已注冊的驅(qū)動，用總線的match方法判斷是否有匹配的驅(qū)動，如果有，則調(diào)用驅(qū)動的probe函數(shù)；在總線上注冊驅(qū)動時，會遍歷該總線上已注冊的設(shè)備，用總線的match方法判斷是否有匹配的設(shè)備，如果有，則調(diào)用驅(qū)動的probe函數(shù)。即，不管是先注冊設(shè)備還是先注冊驅(qū)動，總線的match方法會作用于所有組合，如果匹配了，則調(diào)用驅(qū)動的probe方法，這樣就探測到了。platform_bus是虛擬的總線，沒有具體的協(xié)議。上面所講設(shè)備的結(jié)構(gòu)體是在枚舉時動態(tài)生成的，設(shè)備的注冊也是在枚舉時觸發(fā)的，而platform_device的定義與注冊是在平臺初始化文件里

13、手動做的。后面的情況就是一樣的了。其它一些沒有類似枚舉之類過程的總線，如I2C，也是這種流程。5. 內(nèi)核啟動的時候， platform_device 是優(yōu)先于 platform_driver 注冊的。 比如 platform_device A , 是在arch/arm/mach-XXXX/mach-XXXX.c 文件里注冊的， 而這個文件的代碼是 優(yōu)先于 platform_driver_register 執(zhí)行的。所以在你platform_driver_register執(zhí)行的時候， platform_device A已經(jīng)被掛在platform_bus總線上了， 而platform_driver_

14、register（）有個功能是到platform_bus上去挨個找尋，找尋掛在上面的platform_bus上的platform_device。找到了就執(zhí)行probe（）。6. 可不可以這樣，我沒有試過。但是因?yàn)轵?qū)動中有 開發(fā)者實(shí)現(xiàn)的 probe 函數(shù)。 如果先注冊驅(qū)動， 驅(qū)動就找不到設(shè)備， 從而不執(zhí)行probe函數(shù)，而驅(qū)動中最重要的就是probe函數(shù)，硬件的初始化，寄存器的配置，時鐘的使能都在probe函數(shù)里完成。從這一點(diǎn)來說，驅(qū)動先于設(shè)備注冊，應(yīng)該不可行。7. 你好，關(guān)于I2C驅(qū)動，目前有三個問題想請教下：       1，請問用i2c_add_dr

15、iver注冊I2C的client端的驅(qū)動的時候，這個client是怎么和哪個adapter attach的（在此之前，系統(tǒng)中注冊了四個bit-style的adapter）？注意，我的i2c_driver中，并沒有賦值attach_adapter，但是賦值了probe    2，注冊adapter是用的 i2c_add_adapter，跟了下這個函數(shù)，發(fā)現(xiàn)它c(diǎn)all的是->i2c_register_adapter->                

16、60;                 adap->dev.bus = &i2c_bus_type;                           adap->dev.type = &i2c_adapter_type;     

17、60;                    res = device_register(&adap->dev);          這里是注冊的是一個device，那么根據(jù)device-driver的模型，那adapter的driver是怎么被賦值的呢？   3，i2c_add_driver是向哪跟總線上注冊的，是i2c_bus_type嗎？i2c_regist

18、er_adapter又是向哪跟總線注冊的呢？ 也是i2c_bus_type嗎？   謝謝8. i2c_driver并不是要跟adapter綁定，而是要和i2c_client綁定 。注冊一個i2c_driver時并不知道它支持的設(shè)備在哪條總線上。例如一個系統(tǒng)有兩個i2c控制器，每個控制器上有一個相同型號的EEPROM，它們只需一個i2c_driver。關(guān)鍵在于如何發(fā)現(xiàn)哪條總線上有i2c_driver所支持設(shè)備。老I2C框架里，由i2c_driver負(fù)責(zé)發(fā)現(xiàn)設(shè)備，每注冊一個adapter遍歷已注冊i2c_driver，每注冊一個i2c_driver遍歷已注冊的i2c_adapt

19、er，不讓他們錯過任何一次組合，讓i2c_driver在adapter上探測一下是否有它支持的設(shè)備，如果有，則生成一個i2c_client實(shí)例。當(dāng)然由于i2c協(xié)議很弱，這種探測很不可靠?，F(xiàn)在(尤其在SOC系統(tǒng)中)傾向于靜態(tài)定義這些信息：如果我知道哪條總線上有哪個設(shè)備，我就犯不著讓i2c_driver去找它們了。于是在平臺初始化函數(shù)里注冊i2c_board_info，這個結(jié)構(gòu)體就是一個i2c_client模板。i2c_board_info里有個bus_num作為匹配的憑證，如果bus_num與i2c_adapter的bus_num相同，那就匹配上了。所有注冊的i2c_board_info會放在一個鏈表里，每注冊一個i2c_adapter就去掃描這個鏈表，如果匹配就生成i2c_client。在老框架，i2c_client肯定是在i2c_driver時調(diào)用attach_adapter時出現(xiàn)的；新框架里則可以在沒有i2c_driver的情況下根據(jù)靜態(tài)信息生成i2c_client。另外讓i2c_driver探測設(shè)備時，頂多能知道設(shè)備地址，而欲查詢設(shè)備其它屬性，i2c協(xié)議里沒有通用的方法。而i2c_board_info靜態(tài)了提供了這些屬性。 而對于舊框架，新框架一方面在接口上保持兼容，另一方面在功能上也有更新。新框架里通過bus_num來區(qū)別是掃描