驱动进化之路：总线设备驱动模型
了解总线设备驱动模型之前，可以先了解常规驱动程序的编写：
LED驱动程序框架
驱动设计的思想：面向对象/分层/分离（以LED操作为例）
此次总线设备驱动模型程序的编写基于上述两种框架。
1. 总线设备驱动模型框架
在led_dev.c中注册platform_device结构体，确定硬件信息。在led_drv.c中注册platform_driver结构体。
2. 总线设备驱动模型中两个最重要的结构体
platform维护的所有的驱动都必须要用该结构体定义：
2.1 platform_driver
struct platform_driver {
int (*probe)(struct platform_device *); //
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*resume)(struct platform_device *);
struct device_driver driver;
const struct platform_device_id *id_table;
bool prevent_deferred_probe;
};
该结构体，用于注册驱动到platform总线，
| 成员 | 含义 |
|---|---|
| probe | 当驱动和硬件信息匹配成功之后，就会调用probe函数，驱动所有的资源的注册和初始化全部放在probe函数中 |
| remove | 硬件信息被移除了，或者驱动被卸载了，全部要释放，释放资源的操作就放在该函数中 |
| struct device_driver driver | 内核维护的所有的驱动必须包含该成员，通常driver->name用于和设备进行匹配 |
| const struct platform_device_id *id_table | 往往一个驱动可能能同时支持多个硬件，这些硬件的名字都放在该结构体数组中 |
编写驱动的时候往往需要填充以上几个成员
2.2 platform_device
platform总线用于描述设备硬件信息的结构体，包括该硬件的所有资源（io，memory、中断、DMA等等）。
struct platform_device {
const char *name;
int id;
bool id_auto;
struct device dev;
u32 num_resources;
struct resource *resource;
const struct platform_device_id *id_entry;
char *driver_override; /* Driver name to force a match */
const struct platform_device_id *id_entry;
/* MFD cell pointer */
struct mfd_cell *mfd_cell;
/* arch specific additions */
struct pdev_archdata archdata;
};
| 成员 | 含义 |
|---|---|
| const char *name | 设备的名字，用于和驱动进行匹配的 |
| struct device dev | 内核中维护的所有的设备必须包含该成员， |
| u32 num_resources | 资源个数 |
| struct resource *resource | 描述资源 |
2.3 硬件与驱动的匹配规则
platform_device 与 platform_driver 的匹配
（1）最先比较：platform_device. driver_override和platform_driver.driver.name
可以设置platform_device的driver_override，强制选择某个platform_driver。
（2）然后比较：platform_device.name和platform_driver.id_table[i].name
platform_driver.id_table是“platform_device_id”指针，表示该drv支持若干个device，它里面列出了各个device的{.name, .driver_data}，其中的“name”表示该drv支持的设备的名字，driver_data是些提供给该device的私有数据。
（3）最后比较：platform_device.name和platform_driver.driver.name
platform_driver.id_table可能为空，这时可以根据platform_driver.driver.name来寻找同名的platform_device。
3. 注册/反注册
（1）注册驱动：platform_device_register
/**
* platform_device_register - add a platform-level device
* @pdev: platform device we're adding
*/
int platform_device_register(struct platform_device *pdev){
device_initialize(&pdev->dev);
arch_setup_pdev_archdata(pdev);
return platform_device_add(pdev);
}
（2）注册设备：platform_driver_register
#define platform_driver_register(drv) \
__platform_driver_register(drv, THIS_MODULE)
4. platform_device 与platform_driver 的注册
4.1 platform_driver 定义和注册
#include 4.2 platform_device定义和注册
#include 该程序只用于测试platform框架是否可以成功匹配，struct platform_device hello_device 并没有设置任何硬件信息。
4.3 Makfile
ifneq ($(KERNELRELEASE),)
obj-m:=device.o driver.o
else
KDIR :=/lib/modules/$(shell uname -r)/build
PWD :=$(shell pwd)
all:
make -C $(KDIR) M=$(PWD) modules
clean:
rm -f *.ko *.o *.mod.o *.symvers *.cmd *.mod.c *.order
endif
编译之后，加载模块
5. 实例
原来的框架：
要实现的框架：
文件如下：
程序仍分为上下结构：上层leddrv.c向内核注册file_operations结构体；下层chip_demo_gpio.c提供led_operations结构体来操作硬件。
下层的代码分为2个：chip_demo_gpio.c实现通用的GPIO操作，在里面注册platform_driver 结构体，board_A_led.c指定使用哪个GPIO，即“资源”，在里面注册platform_device结构体，指定硬件资源。
chip_demo_gpio.c实现了单板A对应芯片的GPIO操作，适用于该芯片的所有GPIO引脚。
board_A_led.c则是指定使用哪一个引脚。在board_A_led.c中实现led_resouce结构体，它定义“资源”──要用哪一个引脚。
leddrv.h如下：
#ifndef _LED_RESOURCE_H
#define _LED_RESOURCE_H
/* GPIO3_0 */
/* bit[31:16] = group */
/* bit[15:0] = which pin */
#define GROUP(x) (x>>16)
#define PIN(x) (x&0xFFFF)
#define GROUP_PIN(g,p) ((g<<16) | (p))
#endif
board_A_led.c
board_A_led.c，leddrv.h的实现。
board_A_led.c作为一个可加载模块，里面也有入口函数、出口函数。在入口函数中注册platform_device结构体，在platform_device结构体中指定使用哪个GPIO引脚。
#include led_opr.h：
#ifndef _LED_OPR_H
#define _LED_OPR_H
struct led_operations {
int (*init) (int which); /* 初始化LED, which-哪个LED */
int (*ctl) (int which, char status); /* 控制LED, which-哪个LED, status:1-亮,0-灭 */
};
struct led_operations *get_board_led_opr(void);
#endif
chip_demo_gpio.c
chip_demo_gpio.c，led_opr.h的实现。
chip_demo_gpio.c中注册platform_driver结构体，它使用Bus/Dev/Drv模型，当有匹配的platform_device时，它的probe函数就会被调用。
#include leddrv.h：
#ifndef _LEDDRV_H
#define _LEDDRV_H
#include "led_opr.h"
void led_class_create_device(int minor);
void led_class_destroy_device(int minor);
void register_led_operations(struct led_operations *opr);
#endif /* _LEDDRV_H */
leddrv.c
leddrv.c，leddrv.h的实现。
#include 测试程序ledtest.c：
#include \n" , argv[0]);
return -1;
}
/* 2. 打开文件 */
fd = open(argv[1], O_RDWR);
if (fd == -1){
printf("can not open file %s\n", argv[1]);
return -1;
}
/* 3. 写文件 */
if (0 == strcmp(argv[2], "on")){
status = 1;
write(fd, &status, 1);
}
else{
status = 0;
write(fd, &status, 1);
}
close(fd);
return 0;
}
makefile:
# 1. 使用不同的开发板内核时, 一定要修改KERN_DIR
# 2. KERN_DIR中的内核要事先配置、编译, 为了能编译内核, 要先设置下列环境变量:
# 2.1 ARCH, 比如: export ARCH=arm64
# 2.2 CROSS_COMPILE, 比如: export CROSS_COMPILE=aarch64-linux-gnu-
# 2.3 PATH, 比如: export PATH=$PATH:/home/book/100ask_roc-rk3399-pc/ToolChain-6.3.1/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin
# 注意: 不同的开发板不同的编译器上述3个环境变量不一定相同,
# 请参考各开发板的高级用户使用手册
KERN_DIR = /home/book/100ask_roc-rk3399-pc/linux-4.4
all:
make -C $(KERN_DIR) M=`pwd` modules
$(CROSS_COMPILE)gcc -o ledtest ledtest.c
clean:
make -C $(KERN_DIR) M=`pwd` modules clean
rm -rf modules.order
rm -f ledtest
# 参考内核源码drivers/char/ipmi/Makefile
# 要想把a.c, b.c编译成ab.ko, 可以这样指定:
# ab-y := a.o b.o
# obj-m += ab.o
obj-m += leddrv.o chip_demo_gpio.o board_A_led.o
注意事项
（1）如果platform_device中不提供release函数，如下图所示不提供红框部分的函数：
则在调用platform_device_unregister时会出现警告，如下图所示：
你可以提供一个release函数，如果实在无事可做，把这函数写为空。
（2）EXPORT_SYMBOL
a.c编译为a.ko，里面定义了func_a；如果它想让b.ko使用该函数，那么a.c里需要导出此函数(如果a.c, b.c都编进内核，则无需导出)：
EXPORT_SYMBOL(led_device_create);
并且，使用时要先加载a.ko。
如果先加载b.ko，会有类似如下“Unknown symbol”的提示：
（3）首先，程序是在windows系统编写，在Ubuntu系统上使用交叉工具链编译。编译之后，将生成的文件通过网络设备节点拷贝到开发板上，在开发板上执行驱动的加载。
参考：
手把手教Linux驱动10-platform总线详解