驱动框架3——初步分析led驱动框架源码

以下内容源于朱有鹏《物联网大讲堂》课程的学习整理，如有侵权，请告知删除。

1、涉及到的文件

• led-core.c（一些宏与头文件包含而已）
• led-class.c

（1）分析发现，LED驱动框架中，内核开发者实现的部分主要是led-class.c；

（2）led-class.c其实就是一个内核模块（明显的特征是，有安装和卸载函数）

• 那么对led-class.c的分析应该从下往上，遵从对模块的基本分析方法。

（3）为什么LED驱动框架中，内核开发者实现的部分，要实现成一个模块？

• 因为内核开发者希望这个驱动框架是可以被装载/卸载的。
• 这样当内核使用者不需要这个驱动框架时可以完全去掉，需要时可以随时加上。

（4）led_init函数在/sys/class目录下创建“leds”这个类名；led_exit销毁“leds”这个类名。

2、subsys_initcall宏

（1）subsys_initcall是一个宏，定义在linux/init.h中。

• 功能是，将其声明的函数放到一个特定的段：.initcall4.init。

（2）分析module_init宏，可以看出它将函数放到了.initcall6.init段中。

• module_init
•       __initcall
•             device_initcall
•                  __define_initcall("6",fn,6)

（3）内核在启动过程中，需要按照顺序执行很多事情。内核如何实现按照先后顺序去做很多初始化操作？

• 内核的解决方案：将内核启动时要调用的所有函数归类，然后每个类按照一定的次序去调用执行。
• 这些分类名就叫.initcalln.init，n的值从1到8。
• 内核开发者在编写内核代码时只要将函数设置合适的级别，链接的时候，这些函数就会被放入特定的段，内核启动时再按照（内核链接脚本中指定的）段顺序去依次执行各个段即可。
• 内核链接脚本（编译之后才有）在arch/arm/kernel/vmlinux.lds中。

（4）subsys_initcall和module_init的作用是一样的，只不过前者所声明的函数要比后者在内核启动时的执行顺序更早。

3、led_class_attrs

（1）什么是attribute？

• 对应将来/sys/class/leds/目录里的内容，一般是文件和文件夹。
• 这些文件其实就是sysfs开放给应用层的一些操作接口（非常类似于/dev/目录下的那些设备文件，对这些设备文件的操作API，对应file_operations里面的函数）。

（2）attribute有什么用？

• 让应用程序可以通过/sys/class/leds/目录下面的属性文件（即这些文件代表了某些属性）来操作驱动进而操作硬件设备。

（3）attribute其实是另一条驱动实现的路线（不再有c_dev相关的函数操作），有区别于之前讲的file_operations那条线。

4、led_classdev_register，设备注册函数

• led_classdev_register函数创建一个属于leds这个类的一个设备，其实就是去注册一个设备。
• 这个函数是led驱动框架中，内核开发者提供给SoC厂家驱动开发者的一个注册驱动的接口。
• 当使用led驱动框架去编写驱动的时候，这个led_classdev_register函数的作用，类似于之前使用file_operations方式去注册字符设备驱动时的register_chrdev函数。
• 之前使用file_operations方式时，在sys/class目录下创建一个类，然后再创建属于这个类的一个设备。

5、led_classdev结构体

• 在leds.h文件中