加油加油坚持住！
1、
Linux驱动模型：驱动模型即将各模型中共有的部分抽象成C结构体。Linux2.4版本前无驱动模型的概念，每个驱动写的代码因人而异，随后为规范书写方式，发明了驱动模型，即提取公共信息组成一个个类，为添加设备和驱动提供统一的接口，使得开发变得简单化、规范化，但驱动本身仍然存在开发难度，设备（触摸屏、蓝牙等）的最底层代码不需要驱动工程师搞，Linux设备模型也不需要驱动工程师搞，驱动工程师需要做的是把二者结合。早期的驱动是需要手动inmod的，有驱动模型后直接注册即可。
驱动模型分为四类：类、总线、设备、驱动、Kobject、sysfs、udev。
深入理解Linux设备模型与驱动开发-CSDN博客 (五星推荐)
比如led,rtc,beep,key这类结构简单的设备，它们的控制不需要时序，它们没有相应的物理总线。所以linux内核不会为它们创建驱动总线。为了是这部分设备的驱动开发也能够遵循设备驱动模型，linux内核引入了一种虚拟的总线——平台总线（platform bus）。
2、Linux的底层模型（主要是写内核的人写的，搞驱动的一般不用）
基本结构体Kobject：各类对象的最小单元，对象引用计数（kref）、维护对象链表（entry、parent）、对象上锁（kset）、对用户空间的描述（ktype）。
kobj_type：提供在sysfs下的操作。attribute：sysfs下的属性；sysfs_ops：对象在sysfs下的操作方法。
kset：描述sysfs下的目录关系。
驱动开发注意包含和引用的关系，包含是结构体成员，绑定是指针。如
struct kobject {const char *name;struct list_head entry; // 上下节点 包含关系struct kobject *parent; // 上下层之间 绑定关系struct kset *kset; // 上锁 绑定关系struct kobj_type *ktype;struct sysfs_dirent *sd;struct kref kref; // 对象引用计数unsigned int state_initialized:1;unsigned int state_in_sysfs:1;unsigned int state_add_uevent_sent:1;unsigned int state_remove_uevent_sent:1;unsigned int uevent_suppress:1;
};
3、Linux的上层模型
设备：
struct device是硬件设备在内核驱动框架中的抽象。
device_register用于向内核驱动框架注册一个设备。
通常device不会单独使用，而是被包含在一个具体设备结构体中，如struct usb_device。
驱动：
device_driver是驱动程序在内核驱动框架中的抽象。
name：驱动程序的名字，用于驱动与对应设备的匹配。
probe：用于检测此设备是否可以用本驱动，毕竟不同厂家的设备对应的驱动是不同的。
类：
相关结构体：struct class 和 struct class_device。
class的真正意义在于作为同属于一个class的多个设备的容器
内核中驱动会被类和总线双重管理。
模型思想即面向对象的思想，结构体包一层结构体即类继承类，有一个基类（device_driver），然后创建子类（usb_device）。驱动开发要有思想复杂度！一层套一层。
4、Linux设备总线开发目的是方便管理。
CPU与外部通信的方式：
32位地址总线寻址：片上外设可以通过SOC的内存寻址，因为设备是硬编码进SOC的，硬编码一般是数字前端工程师设计的，使用Verilog HDL语言。（在Linux中设计为平台总线形式，大部分设备均为平台总线）
通过IIC、SPI、USB总线与外部通信。
EXPORT_SYMBOL_GPL的应用：
// 如下代码表示函数允许被其他仅支持GPL的内核模块使用，而不是使用.h声明的方式
void platform_driver_unregister(struct platform_driver *drv)
{driver_unregister(&drv->driver);
}
EXPORT_SYMBOL_GPL(platform_driver_unregister);platfrom设备驱动分析：
// device驱动源码分析static struct platform_driver pm860x_backlight_driver = { // .driver = {.name = "88pm860x-backlight", // name为驱动唯一标识符.owner = THIS_MODULE,},.probe = pm860x_backlight_probe, // 驱动的侦测函数.remove = pm860x_backlight_remove,// 驱动的卸载函数
};static int __init pm860x_backlight_init(void)
{return platform_driver_register(&pm860x_backlight_driver);
}
module_init(pm860x_backlight_init); // 模块注册static void __exit pm860x_backlight_exit(void)
{platform_driver_unregister(&pm860x_backlight_driver);
}
module_exit(pm860x_backlight_exit); // 模块卸载static struct platform_device this_device = {.name = "tv_ntsc", // 设备名，用于内核设备树和其他机制中标识这个设备.id = 0,.dev = {.platform_data = &ntsc_panel_data,}
};static int __init ntsc_init(void) // __init阶段执行，执行完毕后释放该数据段
{int ret;ret = platform_driver_register(&this_driver); // 注册驱动if (!ret) {ret = platform_device_register(&this_device);// 注册成功则注册该设备if (ret)platform_driver_unregister(&this_driver);// 否则，卸载设备，以保持内核稳定性。}return ret;
}module_init(ntsc_init); // 模块注册5、
一个驱动可以对应多个设备。当设备加载进来时，会通过platform_match函数匹配对应的驱动（根据驱动名）。若存在，则调用driver的probe函数完成驱动的安装。
内核提供platform_device，写驱动的人提供platform_driver，可以全局检索name的形式检索驱动对应的设备。
设备于内核中的执行顺序：
s3c24xx_led -->mini2440_led1 -->mini2440_devices-->platform_add_devices-->platform_device_register 完成设备添加，可从/sys目录找到。
然后内核根据设备名s3c24xx_led查找对应的驱动，若存在，则执行。以此实现platform框架下的设备和驱动匹配。
static struct platform_device mini2440_led1 = {.name = "s3c24xx_led",.id = 1,.dev = {.platform_data = &mini2440_led1_pdata, // 这段绑定关系交由各驱动模块自己执行},
};struct device {struct device *parent;
.......
.......void *platform_data; /* Platform specific data, devicecore doesn't touch it */ // 此段指针交由各驱动自行绑定。.......
.......}// driver部分，将
static int s3c24xx_led_probe(struct platform_device *dev)
{struct s3c24xx_led_platdata *pdata = dev->dev.platform_data; // 此处实现自定义数据的赋值操作struct s3c24xx_gpio_led *led;int ret;led = kzalloc(sizeof(struct s3c24xx_gpio_led), GFP_KERNEL);if (led == NULL) {dev_err(&dev->dev, "No memory for device\n");return -ENOMEM;}platform_set_drvdata(dev, led);............
}6、
驱动的核心思考点：
能想清楚数据谁写的？给谁了？从哪里传递到哪里？谁接受到数据干啥了？
想想这么设计的优势、必要性是什么？
自己写一个出来。
以上三条就是驱动开发核心部分，区别是不同驱动对应的不同。
