platform 驱动probe函数中传递的变量问题

hui_se0

在看platform驱动是，发现一个很低能的问题，static int __devinitdm9000_probe(struct platform_device *pdev) 中的struct platform_device *pdev是从那里来的device，跟踪platform_driver_register(&dm9000_driver);一直没有发现platform_device的出现，但是现在probe函数中突然出现了这个变量，那么这个变量是从和而来？

hujinzhi

platform驱动分为platform_driver和platform_device两个结构体表示，前者表示平台驱动，后者表示平台设备，这个struct platform_device *pdev就是在平台相关文件里注册的。平台下会定义一个platform_device,然后platform_device_register(&platform_device)，所以你注册的平台驱动，当在platform_bus上探测到有个设备的时候，这个你之前在平台文件里注册的platform_device就会传过来。

hujinzhi

内核里涉及到probe这样的函数的时候，都是这个原理的。

hyhdez

围观,我也想知道

hyhdez

"platform_bus上探测到有个设备的时候"此句怎么理解,是怎么探测到的呢?

tempname2

驱动肯定是自己注册了。至于设备的注册，有些设备所使用的协议有枚举过程，从这处过程中可以得到设备信息，进而生成相应设备结构体，然后注册在相应总线上。

在总线上注册设备时，会遍历该总线上已注册的驱动，用总线的match方法判断是否有匹配的驱动，如果有，则调用驱动的probe函数；在总线上注册驱动时，会遍历该总线上已注册的设备，用总线的match方法判断是否有匹配的设备，如果有，则调用驱动的probe函数。即，不管是先注册设备还是先注册驱动，总线的match方法会作用于所有组合，如果匹配了，则调用驱动的probe方法，这样就探测到了。

platform_bus是虚拟的总线，没有具体的协议。上面所讲设备的结构体是在枚举时动态生成的，设备的注册也是在枚举时触发的，而platform_device的定义与注册是在平台初始化文件里手动做的。后面的情况就是一样的了。其它一些没有类似枚举之类过程的总线，如I2C，也是这种流程。

hujinzhi

楼上的说得很详细了啊。。呵呵 高手啊 ！

alvininha

内核启动的时候， platform_device 是优先于 platform_driver 注册的。 比如 platform_device A , 是在arch/arm/mach-XXXX/mach-XXXX.c 文件里注册的， 而这个文件的代码是 优先于 platform_driver_register 执行的。
所以在你platform_driver_register执行的时候， platform_device A已经被挂在platform_bus总线上了， 而platform_driver_register（）有个功能是到platform_bus上去挨个找寻，找寻挂在上面的platform_bus上的platform_device。找到了就执行probe（）。

楼主提到static int __devinitdm9000_probe(struct platform_device *pdev)， 当这个函数被调用的时候， 证明已经在platform_bus上找到相应的平台设备了


详细的可以看看我转载的这篇文章http://blog.csdn.net/lihaoweiv/article/details/6804872

tempname2

回复 8# alvininha

驱动先于设备注册应该也无妨。

alvininha

回复  alvininha

驱动先于设备注册应该也无妨。
tempname2 发表于 2011-10-26 12:09

   
可不可以这样，我没有试过。
但是因为驱动中有 开发者实现的 probe 函数。 如果先注册驱动， 驱动就找不到设备， 从而不执行probe函数，而驱动中最重要的就是probe函数，硬件的初始化，寄存器的配置，时钟的使能都在probe函数里完成。从这一点来说，驱动先于设备注册，应该不可行。

不知道有没有高人指点一下呢。