以下内容源于朱有鹏《物联网大讲堂》课程的学习整理，如有侵权，请告知删除。
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
- 对应将来/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文件中
