设备树——platform_driver

一、设备树是什么？

---

除去官方的定义，我学完了设备树（中断那儿）还没有深入了解，我觉得设备树就是device的另外一种描述，总的来看还是platform下的东西，之前我们的设备资源是放在platform的下的device中的，用了设备树也还是，唯一的区别就是什么生成了platform下的设备节点，原来我们用的是device.c去device_create去生成节点，用的是.name去匹配，现在用的是dtb去指定描述，bootloader传给内核，最后也是一样的在platform下去生成相应的device，用compatible去匹配,其实都一样，只是设备树更直观，更简洁，比如你如果指定10个device都需要修改资源的时候，难道要去改10个.c吗，设备树文件一个dts全部搞定，而且设备树的语法也很简单,所以还是很建议的，但是学完明白一个道理，设备树好不好，还是看驱动支持到不到位，你毕竟只是去指定资源，人家驱动用不用是人家的事，所以驱动还是得撸着走啊！*
.
.
.

二、自己写一个简单的LED驱动配合自己的tree

---

【

自己写一个驱动那不肯定就可以随心所欲嘛，自己用设备树提供资源，再用自己写的driver去获取，刚好也练练驱动，就写个灯的驱动，也试试不在windows下面写，直接在服务器上用vim去写一写，刚学了手大佬的操作，以前都是SI。

】

---

首先理一理自己每一步要干嘛，以Module形式那就肯定有module_init,module_exit.

因为是以模块的形式加载的，所以第一肯定是这两个 涉及到insmod rmmod

init: 注册driver到platform

module_init(myled_init);

static int myled_init(void)
{
   
	platform_driver_register(&led_drv);     
	return 0;
}

理解：向平台注册驱动 因为我们采用的是platform的方式，那么不管设备信息device是谁提供怎么提供，驱动必须是我们自己注册进去，所以第一步肯定是向平台注册我们的驱动

’
’
‘

exit: 从platform卸载driver

module_exit(myled_exit);
static void myled_exit(void)
{
   
	platform_driver_unregister(&led_drv);    
}

理解：既然是以Module形式加载那么肯定是可加载也就希望可卸载 不然不如直接编译进内核 所以退出的时候还是要卸载掉驱动

’
’
‘
’

led_drv

这个就是我们的核心了，后续的都是围绕这个展开，我们来一探究竟

struct platform_driver led_drv = {
   
	.probe		= led_probe,
	.remove		= led_remove,
	.driver		= {
   
		.name	= "myled",
		.of_match_table = of_match_leds, /* 能支持哪些来自于dts的platform_device */
	}
}