一. 简介
前面两篇文章中，一篇实现 platform设备注册代码实现，文章如下：
无设备树platform设备驱动实验：platform设备注册代码实现-CSDN博客
一篇文章实现了 platform驱动注册代码框架，文章如下：
无设备树platform设备驱动实验：platform驱动注册代码框架实现-CSDN博客
本文测试设备与驱动是否匹配成功。
验证匹配成功的方法：当都加载了设备注册模块与驱动注册模块后，是否会执行 platform_driver的 probe 函数
二. 无设备树platform设备驱动实验：platform驱动注册代码框架测试
1. 拷贝设备注册模块与驱动注册模块
注意：开发板的系统是通过 nfs服务挂载方式访问 ubuntu系统的。即 系统文件存放在 ubuntu系统所设置的 nfs目录下！而开发板通过 nfs服务加载系统文件。
打开ubuntu系统，进入 16_platform工程目录下，拷贝 设备注册模块与驱动注册模块到开发板系统文件目录下：
wangtian@wangtian-virtual-machine:~/zhengdian_Linux/Linux_Drivers/16_platform$ sudo cp platform_leddevice.ko platform_leddriver.ko /home/wangtian/linux/nfs_File/rootfs/lib/modules/4.1.15/ -f
2. 开发板加载测试
开发板上电后进入系统 /lib/modules/4.1.15/目录下，确认 驱动文件是否已经存在：
可以看出，设备注册模块 platform_leddevice.ko 与 驱动注册模块 platform_leddriver.ko都已经存在。
(1) 加载测试驱动模块
注意：如果选择使用 "modprobe" 命令加载驱动模块，则在驱动程序第一次加载时首先运行 "depmod" 命令！
这里因为 platform_leddevice.ko 前面已经加载过一次，而 platform_leddriver.ko没加载过。
所以，需要运行 "depmod"命令（为了platform_leddriver.ko）：
首先，加载platform_leddevice.ko 设备注册模块，然后，再加载platform_leddriver.ko驱动注册模块：
可以看出，当在继加载platform_leddevice.ko 后，再加载 platform_leddriver.ko后，打印了 probe函数的内部打印信息，说明开发板上已加载的设备与后面的驱动匹配成功。
注意：这里也可以先加载 platform_leddriver.ko后，再加载 platform_leddevice.ko ，也是会打印 probe函数的打印信息的。说明后来加载的驱动模块匹配了已加载的设备。
(2) 查看 /sys/bus/platform/devices目录与 /sys/bus/platform/drivers目录
查看 /sys/bus/platform/devices：
进入/sys/bus/platform/devices目录下，查看是否存在加载的 platform设备：
可以看出，已经存在所加载的 platform设备，设备名为 imx6ull_led，正是我在platform设备注册时 platform_device的成员 name值。
查看 /sys/bus/platform/drivers：
进入/sys/bus/platform/devices目录下，查看是否存在加载的 platform驱动：
可以看出，已经存在所加载的 platform驱动，驱动名为 imx6ull_led，正是我在platform驱动注册时 platform_driver的成员 .driver的 name值。
(3) 卸载驱动模块
卸载驱动模块时，可以确定在卸载驱动模块时，相应的释放资源函数 是否执行。
可以看出，卸载设备注册驱动与 驱动注册驱动都不存在问题。
注意：可以进行反复多次的加载与卸载驱动模块测试，确保驱动代码真正不存在问题。
接下来继续 向 platform_driver驱动注册框架中加入 Led灯操作部分（包括 IO初始化以及led灯亮灭，字符设备驱动框架）。
