probe的调用

probe的调用 最近看到linux的设备驱动模型，关于Kobject、Kset等还不是很清淅。看到了struct device_driver这个结构时，想到一个问题：它的初始化函数到底在哪里调用呢？以前搞PCI驱动时用pci驱动注册函数就可以调用它，搞 s3c2410驱动时只要在mach-smdk2410.c中的struct platform_device *smdk2410_devices {}中加入设备也会调用。但从来就没有想过具体的驱动注册并调用probe的过程。 于是打开SourceInsight追踪了一下： 从driver_register看起： int driver_register(struct device_driver * drv) { klist_init(&drv->klist_devices, klist_devices_get, klist_devices_put); init_completion(&drv->unloaded); return bus_add_driver(drv); } klist_init与init_completion没去管它，可能是2.6的这个设备模型要做的一些工作。直觉告诉我要去bus_add_driver。 bus_add_driver中： 都是些Kobject 与 klist 、attr等。还是与设备模型有关的。但是其中有一句： driver_attach(drv); 单听名字就很像： void driver_attach(struct device_driver * drv) { bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); } 这个熟悉，遍历总线上的设备并设用__driver_attach。 在__driver_attach中又主要是这样： driver_probe_device(drv, dev); 跑到driver_probe_device中去看看： 有一段很重要： if (drv->bus->match && !drv->bus->match(dev, drv)) goto Done; 明显，是调用的驱动的总线上的match函数。如果返回1，则可以继续，否则就Done了。 继承执行的话： if (drv->probe) { ret = drv->probe(dev); if (ret) { dev->driver = NULL; goto ProbeFailed; } 只要probe存在则调用之。至此就完成了probe的调用。 这个过程链的关键还是在drv->bus->match ，因为其余的地方出错的话就是注册失败，而只要注册不失败且match返回1，那么就铁定会调用驱程的probe了。你可以注册一个总线类型和总线,并在 match中总是返回 1, 会发现,只要struct device_driver中的bus类型正确时,probe函数总是被调用. PCI设备有自己的总线模型，估计在它的match中就有一个判断的条件。 static int pci_bus_match(struct device *dev, struct device_driver *drv) { struct pci_dev *pci_dev = to_pci_dev(dev); struct pci_driver *pci_drv = to_pci_driver(drv); const struct pci_device_id *found_id; found_id = pci_match_device(pci_drv, pci_dev); if (found_id) return 1; return 0; } 再往下跟踪就知道主要是根据我们熟悉的id_table来的。 原文地址 http://blog.csdn.net/shawnrong/archive/2007/11/23/1899391.aspx 另外从别处追加以下： 有两个重要的链表挂在bus上，一个是设备device链表，一个是驱动driver链表。 每当我们向一根bus注册一个驱动driver时，套路是这样的： driver_register(struct device_driver * drv) -> bus_add_driver() -> driver_attach() -> bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); bus_for_each_dev遍历该总线上所有的device，执行一次__driver_attach()，看能不能将驱动关联(attach)到某个设备上去。 __driver_attach() ->driver_probe_device() ->drv->bus->match(dev, drv), // 调用bus的match函数，看device和driver匹不匹配。如果匹配上， 继续执行really_probe()。 ->really_probe() ->driver->probe()。(如果bus->probe非空，则调用bus->probe) 而每当我们向一根bus添加一个硬件时时，套路是这样的： device_add() \\ device_add 中有很多操作kobject，注册sysfs，形成硬件hiberarchy结构的代码。 如果您忘记了，先回头去参考参考"我是sysfs" ->bus_attach_device() -> device_attach() ->bus_for_each_drv() bus_for_each_drv与bus_for_each_dev类似，遍历该总线上所有的driver，执行一次__device_attach()，看能不能将设备关联(attach)到某个已登记的驱动上去。 __device_attach() ->driver_probe_device() //后面与上面一样 总结一些，一句话，注册一个某个bus的驱动就是先把驱动自己链入到bus驱动链表中去，在从bus的设备链表中一一寻找，看有没有自己可以关联上的设备。找到就probe，再把二者bind起来。反之，添加设备道理也是一样的。

最近看到linux的设备驱动模型，关于Kobject、Kset等还不是很清淅。看到了struct device_driver这个结构时，想到一个问题：它的初始化函数到底在哪里调用呢？以前搞PCI驱动时用pci驱动注册函数就可以调用它，搞 s3c2410驱动时只要在mach-smdk2410.c中的struct platform_device *smdk2410_devices {}中加入设备也会调用。但从来就没有想过具体的驱动注册并调用probe的过程。 于是打开SourceInsight追踪了一下： 从driver_register看起： int driver_register(struct device_driver * drv) { klist_init(&drv->klist_devices, klist_devices_get, klist_devices_put); init_completion(&drv->unloaded); return bus_add_driver(drv); } klist_init与init_completion没去管它，可能是2.6的这个设备模型要做的一些工作。直觉告诉我要去bus_add_driver。 bus_add_driver中： 都是些Kobject 与 klist 、attr等。还是与设备模型有关的。但是其中有一句： driver_attach(drv); 单听名字就很像： void driver_attach(struct device_driver * drv) { bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); } 这个熟悉，遍历总线上的设备并设用__driver_attach。 在__driver_attach中又主要是这样： driver_probe_device(drv, dev); 跑到driver_probe_device中去看看： 有一段很重要： if (drv->bus->match && !drv->bus->match(dev, drv)) goto Done; 明显，是调用的驱动的总线上的match函数。如果返回1，则可以继续，否则就Done了。 继承执行的话： if (drv->probe) { ret = drv->probe(dev); if (ret) { dev->driver = NULL; goto ProbeFailed; } 只要probe存在则调用之。至此就完成了probe的调用。 这个过程链的关键还是在drv->bus->match ，因为其余的地方出错的话就是注册失败，而只要注册不失败且match返回1，那么就铁定会调用驱程的probe了。你可以注册一个总线类型和总线,并在 match中总是返回 1, 会发现,只要struct device_driver中的bus类型正确时,probe函数总是被调用. PCI设备有自己的总线模型，估计在它的match中就有一个判断的条件。 static int pci_bus_match(struct device *dev, struct device_driver *drv) { struct pci_dev *pci_dev = to_pci_dev(dev); struct pci_driver *pci_drv = to_pci_driver(drv); const struct pci_device_id *found_id; found_id = pci_match_device(pci_drv, pci_dev); if (found_id) return 1; return 0; } 再往下跟踪就知道主要是根据我们熟悉的id_table来的。 原文地址 http://blog.csdn.net/shawnrong/archive/2007/11/23/1899391.aspx 另外从别处追加以下： 有两个重要的链表挂在bus上，一个是设备device链表，一个是驱动driver链表。 每当我们向一根bus注册一个驱动driver时，套路是这样的： driver_register(struct device_driver * drv) -> bus_add_driver() -> driver_attach() -> bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); bus_for_each_dev遍历该总线上所有的device，执行一次__driver_attach()，看能不能将驱动关联(attach)到某个设备上去。 __driver_attach() ->driver_probe_device() ->drv->bus->match(dev, drv), // 调用bus的match函数，看device和driver匹不匹配。如果匹配上， 继续执行really_probe()。 ->really_probe() ->driver->probe()。(如果bus->probe非空，则调用bus->probe) 而每当我们向一根bus添加一个硬件时时，套路是这样的： device_add() \\ device_add 中有很多操作kobject，注册sysfs，形成硬件hiberarchy结构的代码。 如果您忘记了，先回头去参考参考"我是sysfs" ->bus_attach_device() -> device_attach() ->bus_for_each_drv() bus_for_each_drv与bus_for_each_dev类似，遍历该总线上所有的driver，执行一次__device_attach()，看能不能将设备关联(attach)到某个已登记的驱动上去。 __device_attach() ->driver_probe_device() //后面与上面一样 总结一些，一句话，注册一个某个bus的驱动就是先把驱动自己链入到bus驱动链表中去，在从bus的设备链表中一一寻找，看有没有自己可以关联上的设备。找到就probe，再把二者bind起来。反之，添加设备道理也是一样的。