platform_device 与 platform_driver 是如何匹配的？

        我们知道 platform_device 注册到内核以后，当我们每注册一个 platform_driver 时，它们就会两两确定是否能够匹配，如果能够配对成功，就会调用 platform_driver 的 probe() 函数。

platform_device 是怎么来的呢？一般有三种来源

1、从设备树的某些节点转换而来 (具体哪些节点才能够转换呢？请参考下一篇)

2、平台厂商注册而来，比如 TI 的 gpio 子系统的实现方式,其他厂商也类似。

linux-4.9/arch/arm/mach-omap2/gpio.c   （ platform_device  的注册 ）

linux-4.9/drivers/gpio/gpio-omap.c     （ platform_driver  的注册 ）

这样才有了各个平台都可以在 使用 gpio 子系统的函数API gpio_set_value() 等

3、自己写的平台设备，比如板子需要在总线上扩展两个网卡，这时候就需要自己完成 platform_device 的描述

我们先来看看 内核对设备树的处理流程

① dts在PC机上被编译为dtb文件；
② u-boot把dtb文件传给内核；
③ 内核解析dtb文件，把每一个节点都转换为 device_node 结构体；
④ 对于某些 device_node 结构体，会被转换为 platform_device 结构体。

dtb中的每一个节点都会被转化成 device_node 结构体

 

那到底哪些 设备节点 最终会被转换成 platform_device 呢？

A. 根节点 下含有compatile属性的子节点 ( 1级子节点 )

B. 含有 特定compatile 属性的节点的子节点 ( 2级子节点)

       如果一个节点的compatile属性，它的值是这4者之一：”simple-bus”,”simple-mfd”,”isa”,”arm,amba-bus”,
  那么它的子结点(需含compatile属性)也可以转换为 platform_device 。

			/ {   
				  mytest {   
					  compatile = "mytest", "simple-bus";   
					  mytest@0 {   
							compatile = "mytest_0";   
					  };   
				  };   
               }

    /mytest 节点因为含有 compatile 属性，会被转化为 platform_device

    /mytest/mytest@0  节点有 compatile 属性，且父节点兼容 "simple-bus" 属性，也会被转化为 platform_device.

   一般2级子节点是不会转化为 platform_device 的，”simple-bus” 是专门为开发者创造的，如果你想让你添加的 2级子节点转化为 platform_device ，就可以添加这个属性。

 

C. 总线I2C、SPI节点下的子节点：不转换为platform_device
 某个总线下到子节点，应该交给对应的总线驱动程序来处理, 它们不应该被转换为platform_device

        

			/ {   
				    
				  i2c {   
					  compatile = "samsung,i2c";   
					  at24c02 {   
							compatile = "at24c02";                   
					  };   
				  };   
			   
				  spi {   
					  compatile = "samsung,spi";             
					  flash@0 {   
							compatible = "winbond,w25q32dw";   
							spi-max-frequency = <25000000>;   
							reg = <0>;   
						  };   
				  };   
			  };   

/i2c节点一般表示i2c控制器, 它会被转换为platform_device, 在内核中有对应的platform_driver;

/i2c/at24c02节点不会被转换为platform_device, 它被如何处理完全由父节点的platform_driver决定, 一般是被创建为一个i2c_client。

类似的也有/spi节点, 它一般也是用来表示SPI控制器, 它会被转换为platform_device, 在内核中有对应的platform_driver; /spi/flash@0节点不会被转换为platform_device, 它被如何处理完全由父节点的platform_driver决定, 一般是被创建为一个spi_device。

怎么转换为platform_device

内核处理设备树的函数调用过程，这里不去分析；我们只需要得到如下结论：
  A. platform_device中含有resource数组, 它来自 device_node 的 reg, interrupts 属性;
  B. platform_device->dev->of_node 指向 device_node, 可以通过它获得其他属 性

 

platform_device如何与platform_driver 匹配呢？

        我们知道 platform_device 注册到内核以后，当我们每注册一个 platform_driver 时，它们就会两两确定是否能够匹配，如果能够配对成功，就会调用 platform_driver 的 probe() 函数。

 匹配规则如下 ： 

最先比较：是否强制选择某个driver 

  比较platform_device. driver_override和platform_driver.driver.name
  可以设置platform_device的driver_override，强制选择某个platform_driver。

然后比较：设备树信息

  比较：platform_device. dev.of_node和platform_driver.driver.of_match_table。

 由设备树节点转换得来的platform_device中，含有一个结构体：of_node。
  它的类型如下：

如果一个platform_driver支持设备树，它的platform_driver.driver.of_match_table是一个数组，类型如下：

使用设备树信息来判断dev和drv是否配对时，判断的顺序为  compatile -->  type --> name  ，其中要是有一个判断成功，则返回成功。

接下来比较：platform_device_id

比较platform_device. name和platform_driver.id_table[i].name，id_table中可能有多项。

platform_driver.id_table是“platform_device_id”指针，表示该drv支持若干个device，它里面列出了各个device的{.name, .driver_data}，其中的“name”表示该drv支持的设备的名字，driver_data是些提供给该device的私有数据。

最后比较：platform_device.name 和 platform_driver.driver.name

  platform_driver.id_table可能为空，
  这时可以根据platform_driver.driver.name来寻找同名的platform_device。

 

 

一个图概括所有的配对过程

 

 

 

 

Reference : https://book.100ask.org/source/chapterfive/ELADCMSecondEditionChapterFive.html#id87