在linux内核中 已做好各类驱动的框架，驱动程序也属于内核的一部分，我们可以在原有的驱动上修改，来匹配我们自已的硬件，也可以自已编写符合内核驱动框架的驱动程序。出于学习的目的，便于更好的理解各类驱动的框架和编程思想，先分析内核自带的驱动框架和流程，再自已编写符合内核框架的驱动程序。下面开始，从输入子系统开始学习分析，后面一步一步涉及各类驱动。
一、输入子系统
从 drivers/input/input.c 这个文件开始分析，分析驱动程序的时候，先从其入口函数开始，因为每当加载一个驱动程序的时候就是调用这个驱动的入口函数，后面我们就假设对一个驱动的读写操作，一步一步展开深入，分析其流程，从而得到框架，当我们自已写驱动时就可以参照这个框架一步步编写程序，实现功能。
1 /* 定义一个 file_operations 结构体 并设置 */
2 static const struct file_operations input_fops = {
3 .owner = THIS_MODULE,
4 .open = input_open_file,
5 .llseek = noop_llseek,
6 };
7
8 static int __init input_init(void)
9 {
10 int err;
11 /* 注册一个 input_class 类 */
12 err = class_register(&input_class);
13 if (err) {
14 pr_err("unable to register input_dev class\n");
15 return err;
16 }
17
18 err = input_proc_init();
19 if (err)
20 goto fail1;
21 /* 注册一个字符设备 参数:INPUT_MAJOR-主设备号 "input"-名字 input_fops-file_operations 结构体 */
22 err = register_chrdev(INPUT_MAJOR, "input", &input_fops);
23 if (err) {
24 pr_err("unable to register char major %d", INPUT_MAJOR);
25 goto fail2;
26 }
27
28 return 0;
29
30 fail2: input_proc_exit();
31 fail1: class_unregister(&input_class);
32 return err;
33 }
A：假设我们的应用程序打开这个设备，那么就会调用这个设备的open函数，上面注册设备时，传入了一个 file_operations 结构体，他里面有一个 open = input_open_file 进入这个函数来分析
static int input_open_file(struct inode *inode, struct file *file)
{
/* 定义一个 input_handler 结构体指针 */
struct input_handler *handler;
/* 定义两个file_operations 结构体指针 */
const struct file_operations *old_fops, *new_fops = NULL;
int err;
/* 互斥锁 上锁 */
err = mutex_lock_interruptible(&input_mutex);
if (err)
return err;
/* 设置 handler 指向 以打开设备的次设备号右移5位的值为下标
* 取出 input_table【下标】 数组的一项 赋给 handler
*/
/* No load-on-demand here? */
handler = input_table[iminor(inode) >> 5];
/* 判断这项是否存在 1-存在 0-不存在 */
if (handler)
/* 把 handler 里的 file_operations 结构体 赋给 new_fops */
new_fops = fops_get(handler->fops);
/* 互斥锁 解锁 */
mutex_unlock(&input_mutex);
/*
* That‘s _really_ odd. Usually NULL ->open means "nothing special",
* not "no device". Oh, well...
*/
if (!new_fops || !new_fops->open) {
fops_put(new_fops);
err = -ENODEV;
goto out;
}
/* 保存原来的 file_operations 并把新的new_fops 赋给file->f_op */
old_fops = file->f_op;
file->f_op = new_fops;
/* 调用新的fops里的open函数
* 即执行的是 handler->fops->open 函数
*/
err = new_fops->open(inode, file);
if (err) {
fops_put(file->f_op);
file->f_op = fops_get(old_fops);
}
fops_put(old_fops);
out:
return err;
}
到这里，我们就知道了，APP执行open时，最终会调用到 handler->fops->open 函数，那么，handler->fops->open 函数是谁呢？这个函数从那里来的？谁创建设置这个函数？
在上面的代码里有一条 handler = input_table[iminor(inode) >> 5]; 从 input_table 数组中得到，那这个数组又是谁构造和填充设置的呢？这个数组是一个静态数组，所以在本文件中搜索一下应该可以知道结果。
static struct input_handler *input_table[8];
int input_register_handler(struct input_handler *handler)
{
/* 定义一个 input_dev 结构体指针 */
struct input_dev *dev;
int retval;
/* 互斥锁 上锁 */
retval = mutex_lock_interruptible(&input_mutex);
if (retval)
return retval;
/* 初始化链表头 */
INIT_LIST_HEAD(&handler->h_list);
/* 判断 handler->fops 是否存在 判断 input_table[handler->minor >> 5]
* 数组里这项是否存在 存在就返回忙错误 跳到 out处
*/
if (handler->fops != NULL) {
if (input_table[handler->minor >> 5]) {
retval = -EBUSY;
goto out;
}
/* 把这个函数的参数 handler 赋给这一项 即设置数组这一项，open 里要用到 */
input_table[handler->minor >> 5] = handler;
}
/* 把这个结构体加入 input_handler_list 链表 */
list_add_tail(&handler->node, &input_handler_list);
/* 遍历 input_dev_list 链表 对这个链表的每一个节点都执行 input_attach_handler(dev, handler); */
list_for_each_entry(dev, &input_dev_list, node)
/* 这个函数是比较dev和handler里的id 是否匹配 */
input_attach_handler(dev, handler);
input_wakeup_procfs_readers();
out:
mutex_unlock(&input_mutex);
return retval;
}
搜索得到在 int input_register_handler(struct input_handler *handler) 函数里构造设置了，这里传入的参数 struct input_handler *handler 我们不清楚是那来的，再搜索那里调用了 input_register_handler 把参数搞清楚
得到很多文件调用了这个函数，我们选一个简单的来分析 就以 Evdev.c 为例来分析一下，了解一个 传入参数是什么内容。进入 evdev.c 分析。
Apm-power.c (drivers\input): return input_register_handler(&apmpower_handler);
Evbug.c (drivers\input): return input_register_handler(&evbug_handler);
Evdev.c (drivers\input): return input_register_handler(&evdev_handler);
Input.c (drivers\input): * input_register_handler - register a new input handler
Input.c (drivers\input):int input_register_handler(struct input_handler *handler)
Input.c (drivers\input):EXPORT_SYMBOL(input_register_handler);
Input.c (net\rfkill): return input_register_handler(&rfkill_handler);
Input.h (include\linux):int __must_check input_register_handler(struct input_handler *);
Joydev.c (drivers\input): return input_register_handler(&joydev_handler);
Keyboard.c (drivers\tty\vt): error = input_register_handler(&kbd_handler);
Kgdboc.c (drivers\tty\serial): if (input_register_handler(&kgdboc_reset_handler) == 0)
Mac_hid.c (drivers\macintosh): err = input_register_handler(&mac_hid_emumouse_handler);
Mousedev.c (drivers\input): error = input_register_handler(&mousedev_handler);
Sysrq.c (drivers\tty): error = input_register_handler(&sysrq_handler);
static struct input_handler evdev_handler = {
.event = evdev_event, /* 事件处理函数 */
.connect = evdev_connect, /* 连接函数 设备层和 软件处理层连接 */
.disconnect = evdev_disconnect, /* 清除连接 */
.fops = &evdev_fops, /* file_operations 结构体 */
.minor = EVDEV_MINOR_BASE, /* 次设备号 */
.name = "evdev", /* 名字 */
.id_table = evdev_ids, /* ID 用于和设备层匹配 */
};
static int __init evdev_init(void)
{
/* 注册一个 input_register_handler */
return input_register_handler(&evdev_handler);
}
我们可以看到，是在入口函数里调用了 input_register_handler 这个函数，这个参数就是 input_handler 结构体，可以看到这个结构体里很多函数，file_operations 结构体 等等，从这里我们基本就可以确定在前的所需要用到的一些值和函数了。下面简单列出一些相对重要的参数。
/* input_table[handler->minor >> 5] = handler;
* handler->minor >> 5 = 64 >> 5 = 2
* handler = evdev_handler
* input_table[2] = evdev_handler
*/
/* err = new_fops->open(inode, file);
* new_fops->open = evdev_fops->evdev_open(inode, file);
*/
static const struct file_operations evdev_fops = {
.owner = THIS_MODULE,
.read = evdev_read,
.write = evdev_write,
.poll = evdev_poll,
.open = evdev_open,
.release = evdev_release,
.unlocked_ioctl = evdev_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = evdev_ioctl_compat,
#endif
.fasync = evdev_fasync,
.flush = evdev_flush,
.llseek = no_llseek,
};
由此得知，当app应用层调用操作时，最终会调用到 input_handler 结构体里的操作函数 事实上如果跟着分析下去还有很多东西，如果现在跟得太深，不太好理解，所以暂时对于handler层 先分析到这里，后面的内容和另一个层 设备层是一起的，所以下面转过头先分析设备层，等到设备层分析到和handler层相接的地方，在往下分析，由此可以便于加深理解，为什么我知道有个设备层呢？“我也是跟别人学的” 但是有一点可以看出来，上面分析的过程中，出现过一个东西在 input_register_handler 这个函里有一段处理
/* 把这个结构体加入 input_handler_list 链表 */
list_add_tail(&handler->node, &input_handler_list);
/* 遍历 input_dev_list 链表 对这个链表的每一个节点都执行 input_attach_handler(dev, handler); */
list_for_each_entry(dev, &input_dev_list, node)
/* 这个函数是比较dev和handler里的id 是否匹配 */
input_attach_handler(dev, handler);
这里提到一个链表 input_dev_list 这就是设备层的链表，我们搜索一下，看在那里可以找到相关的信息，搜索到一些内容，我们依次进去看一下，看在那里有这个链表的处理 最终我搜索到一条这样的处理
list_add_tail(&dev->node, &input_dev_list); 这条处理就把dev结构体加入input_dev_list这个链表，在 int input_register_device(struct input_dev *dev) 函数里调用，看名字就是注册一个输入设备，参数是input_dev 结构体
和我们前面看到的注册类同，因此我们再搜索一下谁调用了这个函数 结果是 一大堆设备调用了这个函数，由此我猜测，调用这个函数的就是设备层关于硬件相关的驱动，你问我怎么知道，因为我是天才！！！开个玩笑，我要是天才就不用学了。。。当然我也是跟别人学的。所谓的别人就是“韦东山大牛” 这不是广告，纯属个人觉得，他的东西确实好，好像跑偏了。回到正题。刚说到搜索到很多调用，我们选一个简单点的来分析一下，设备层这边的框架，现在分析的东西，就是我们自已写驱动所需要编写的内容，了解了这层的框架和逻辑思维后，按照框架就可以写出符合内核的驱动程序了，同上面一样，找一个简单的例子分析，我里我们选择 gpio_key.c 这只是一个例子，他没有具体的硬件操作。下面开始
在 static int __devinit gpio_keys_probe(struct platform_device *pdev) 这个函数中调用了 error = input_register_device(input); 和上面一样，注册一个input_dev 设备，关于 gpio_keys_probe 是和平台设备相关，我们先不管他我们写驱动时也可以不管他，直接注册设备即可，在这里了解一下 注册前需要做那些事，看代码
static int __devinit gpio_keys_probe(struct platform_device *pdev)
{
const struct gpio_keys_platform_data *pdata = pdev->dev.platform_data;
struct gpio_keys_drvdata *ddata;
struct device *dev = &pdev->dev;
struct gpio_keys_platform_data alt_pdata;
struct input_dev *input;
int i, error;
int wakeup = 0;
if (!pdata) {
error = gpio_keys_get_devtree_pdata(dev, &alt_pdata);
if (error)
return error;
pdata = &alt_pdata;
}
ddata = kzalloc(sizeof(struct gpio_keys_drvdata) +
pdata->nbuttons * sizeof(struct gpio_button_data),
GFP_KERNEL);
/* 分配一个 inpu_dev 结构体 前面有定义的 struct input_dev *input; */
input = input_allocate_device();
if (!ddata || !input) {
dev_err(dev, "failed to allocate state\n");
error = -ENOMEM;
goto fail1;
}
ddata->input = input;
ddata->n_buttons = pdata->nbuttons;
ddata->enable = pdata->enable;
ddata->disable = pdata->disable;
mutex_init(&ddata->disable_lock);
platform_set_drvdata(pdev, ddata);
input_set_drvdata(input, ddata);
/* 这里有一堆设置 input_dev 结构体的 我们自已编写的时候用到什么函数就实现什么函数这里是例子 */
input->name = pdata->name ? : pdev->name;
input->phys = "gpio-keys/input0";
input->dev.parent = &pdev->dev;
input->open = gpio_keys_open; /* open 函数 */
input->close = gpio_keys_close;
input->id.bustype = BUS_HOST;
input->id.vendor = 0x0001;
input->id.product = 0x0001;
input->id.version = 0x0100;
/* Enable auto repeat feature of Linux input subsystem */
if (pdata->rep)
__set_bit(EV_REP, input->evbit);
for (i = 0; i < pdata->nbuttons; i++) {
const struct gpio_keys_button *button = &pdata->buttons[i];
struct gpio_button_data *bdata = &ddata->data[i];
error = gpio_keys_setup_key(pdev, input, bdata, button);
if (error)
goto fail2;
if (button->wakeup)
wakeup = 1;
}
error = sysfs_create_group(&pdev->dev.kobj, &gpio_keys_attr_group);
if (error) {
dev_err(dev, "Unable to export keys/switches, error: %d\n",
error);
goto fail2;
}
/* 注册 input_dev */
error = input_register_device(input);
if (error) {
dev_err(dev, "Unable to register input device, error: %d\n",
error);
goto fail3;
}
/* get current state of buttons that are connected to GPIOs */
for (i = 0; i < pdata->nbuttons; i++) {
struct gpio_button_data *bdata = &ddata->data[i];
if (gpio_is_valid(bdata->button->gpio))
gpio_keys_gpio_report_event(bdata);
}
input_sync(input);
device_init_wakeup(&pdev->dev, wakeup);
return 0;
fail3:
sysfs_remove_group(&pdev->dev.kobj, &gpio_keys_attr_group);
fail2:
while (--i >= 0)
gpio_remove_key(&ddata->data[i]);
platform_set_drvdata(pdev, NULL);
fail1:
input_free_device(input);
kfree(ddata);
/* If we have no platform_data, we allocated buttons dynamically. */
if (!pdev->dev.platform_data)
kfree(pdata->buttons);
return error;
}
我们看到，在注册前，分配了一个input_dev 结构体 并设置他。然后调用注册函数，我们到注册函数里看一下做了些什么鬼事情？
int input_register_device(struct input_dev *dev)
{
/* 这是什么鬼，不认识 不管他 */
static atomic_t input_no = ATOMIC_INIT(0);
/* 定义一个 input_handler 结构体 */
struct input_handler *handler;
const char *path;
int error;
/* Every input device generates EV_SYN/SYN_REPORT events. */
__set_bit(EV_SYN, dev->evbit);
/* KEY_RESERVED is not supposed to be transmitted to userspace. */
__clear_bit(KEY_RESERVED, dev->keybit);
/* Make sure that bitmasks not mentioned in dev->evbit are clean. */
input_cleanse_bitmasks(dev);
if (!dev->hint_events_per_packet)
dev->hint_events_per_packet =
input_estimate_events_per_packet(dev);
/*
* If delay and period are pre-set by the driver, then autorepeating
* is handled by the driver itself and we don‘t do it in input.c.
*/
init_timer(&dev->timer); /* 应该是初始化定时器 */
if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
dev->timer.data = (long) dev;
dev->timer.function = input_repeat_key;
dev->rep[REP_DELAY] = 250;
dev->rep[REP_PERIOD] = 33;
}
if (!dev->getkeycode)
dev->getkeycode = input_default_getkeycode;
if (!dev->setkeycode)
dev->setkeycode = input_default_setkeycode;
dev_set_name(&dev->dev, "input%ld",
(unsigned long) atomic_inc_return(&input_no) - 1);
error = device_add(&dev->dev);
if (error)
return error;
path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
pr_info("%s as %s\n",
dev->name ? dev->name : "Unspecified device",
path ? path : "N/A");
kfree(path);
/* 互斥锁 上锁 老是有这东东，怎么互斥怎么锁，没空理它以后再说 */
error = mutex_lock_interruptible(&input_mutex);
if (error) {
device_del(&dev->dev);
return error;
}
/* 把 input_dev 加入 input_dev_list 链表 */
list_add_tail(&dev->node, &input_dev_list);
/* 遍历 input_handler_list 链表 对每一项都执行input_attach_handler 函数 */
list_for_each_entry(handler, &input_handler_list, node)
input_attach_handler(dev, handler);
input_wakeup_procfs_readers();
mutex_unlock(&input_mutex);
return 0;
}
我们看到了在后面同样是加入了链表，同样也遍历链表，执行相同的函数，在dve层是遍历 input_headler_list链表 在handler层是遍历 input_dev_list链表 嗯，我主场我做主，我找你，你主场你做主，你找我，谁是你，谁是我，你高兴就好，爱谁谁。两个层都调用了相同的函数 input_attach_handler 所以我们很有必要去看一下他想干啥，
static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)
{
const struct input_device_id *id;
int error;
/* 找好基友函数 对比ID 是否相同，相同的话返回值 id=1 */
id = input_match_device(handler, dev);
if (!id)
return -ENODEV;
/* 上面必须返回1才会执行这条 即调用handr层的connect函数 */
error = handler->connect(handler, dev, id);
if (error && error != -ENODEV)
pr_err("failed to attach handler %s to device %s, error: %d\n",
handler->name, kobject_name(&dev->dev.kobj), error);
return error;
}
里面还有一个函数我们再进去看看
static const struct input_device_id *input_match_device(struct input_handler *handler,
struct input_dev *dev)
{
const struct input_device_id *id;
int i;
for (id = handler->id_table; id->flags || id->driver_info; id++) {
if (id->flags & INPUT_DEVICE_ID_MATCH_BUS)
if (id->bustype != dev->id.bustype)
continue;
if (id->flags & INPUT_DEVICE_ID_MATCH_VENDOR)
if (id->vendor != dev->id.vendor)
continue;
if (id->flags & INPUT_DEVICE_ID_MATCH_PRODUCT)
if (id->product != dev->id.product)
continue;
if (id->flags & INPUT_DEVICE_ID_MATCH_VERSION)
if (id->version != dev->id.version)
continue;
MATCH_BIT(evbit, EV_MAX);
MATCH_BIT(keybit, KEY_MAX);
MATCH_BIT(relbit, REL_MAX);
MATCH_BIT(absbit, ABS_MAX);
MATCH_BIT(mscbit, MSC_MAX);
MATCH_BIT(ledbit, LED_MAX);
MATCH_BIT(sndbit, SND_MAX);
MATCH_BIT(ffbit, FF_MAX);
MATCH_BIT(swbit, SW_MAX);
if (!handler->match || handler->match(handler, dev))
return id;
}
return NULL;
}
就是看一下 handler->id_tabe 支不支持 dev，支持就返回1 我们看到 handler->id_tabe 里说了，匹配所有设备，然后调用handler->connect,进去看看这个函数干啥？
static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
const struct input_device_id *id)
{
struct evdev *evdev;
int minor;
int error;
for (minor = 0; minor < EVDEV_MINORS; minor++)
if (!evdev_table[minor])
break;
if (minor == EVDEV_MINORS) {
pr_err("no more free evdev devices\n");
return -ENFILE;
}
evdev = kzalloc(sizeof(struct evdev), GFP_KERNEL);
if (!evdev)
return -ENOMEM;
INIT_LIST_HEAD(&evdev->client_list);
spin_lock_init(&evdev->client_lock);
mutex_init(&evdev->mutex);
init_waitqueue_head(&evdev->wait);
dev_set_name(&evdev->dev, "event%d", minor);
evdev->exist = true;
evdev->minor = minor;
evdev->handle.dev = input_get_device(dev);
evdev->handle.name = dev_name(&evdev->dev);
evdev->handle.handler = handler;
evdev->handle.private = evdev;
evdev->dev.devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);
evdev->dev.class = &input_class;
evdev->dev.parent = &dev->dev;
evdev->dev.release = evdev_free;
device_initialize(&evdev->dev);
error = input_register_handle(&evdev->handle);
if (error)
goto err_free_evdev;
error = evdev_install_chrdev(evdev);
if (error)
goto err_unregister_handle;
error = device_add(&evdev->dev);
if (error)
goto err_cleanup_evdev;
return 0;
err_cleanup_evdev:
evdev_cleanup(evdev);
err_unregister_handle:
input_unregister_handle(&evdev->handle);
err_free_evdev:
put_device(&evdev->dev);
return error;
}
这里面又分配设置了一个input_headle 结构体 注意看名称，少了个 r
evdev->handle.dev = input_get_device(dev);
evdev->handle.name = dev_name(&evdev->dev);
evdev->handle.handler = handler;
evdev->handle.private = evdev;
一个指向 handler 一个指向dev 所以无论从那边进入都可以找到对方，到此双方就建立“基友”的连接关系了。
B：假设app读操作，通过上面的分析我们知道最终会调用到对应的handler里的fops里的read函数，我们来看一下他怎么读的
static ssize_t evdev_read(struct file *file, char __user *buffer,
size_t count, loff_t *ppos)
{
struct evdev_client *client = file->private_data;
struct evdev *evdev = client->evdev;
struct input_event event;
int retval = 0;
if (count < input_event_size())
return -EINVAL;
if (!(file->f_flags & O_NONBLOCK)) {
retval = wait_event_interruptible(evdev->wait,/* 休眠 谁来唤醒 搜索evdev->wait */
client->packet_head != client->tail ||
!evdev->exist);
if (retval)
return retval;
}
if (!evdev->exist)
return -ENODEV;
while (retval + input_event_size() <= count &&
evdev_fetch_next_event(client, &event)) {
if (input_event_to_user(buffer + retval, &event))
return -EFAULT;
retval += input_event_size();
}
if (retval == 0 && (file->f_flags & O_NONBLOCK))
return -EAGAIN;
return retval;
}
在读函数里休眠，那谁来唤醒他呢，他在那个队列里休眠，我们就搜索这个队列，看在那里有唤醒操作 在static void evdev_event(struct input_handle *handle）函数里调用 wake_up_interruptible(&evdev->wait); 来唤醒，谁又调用了evdev_event 函数呢 别人猜得很准，说是从设备层那边会调用到这个函数，用例子来说明，当有按键按下时，进入设备层中断处理函数 在里面会调用inpu_event,分析这个函数可以知道如何操作
static irqreturn_t gpio_keys_irq_isr(int irq, void *dev_id)
{
struct gpio_button_data *bdata = dev_id;
const struct gpio_keys_button *button = bdata->button;
struct input_dev *input = bdata->input;
unsigned long flags;
BUG_ON(irq != bdata->irq);
spin_lock_irqsave(&bdata->lock, flags);
if (!bdata->key_pressed) {
input_event(input, EV_KEY, button->code, 1);
input_sync(input);
if (!bdata->timer_debounce) {
input_event(input, EV_KEY, button->code, 0);
input_sync(input);
goto out;
}
bdata->key_pressed = true;
}
if (bdata->timer_debounce)
mod_timer(&bdata->timer,
jiffies + msecs_to_jiffies(bdata->timer_debounce));
out:
spin_unlock_irqrestore(&bdata->lock, flags);
return IRQ_HANDLED;
}
这里就简单列出调用关系，就不做进一步细化分析了
inpu_event
input_handle_event
input_pass_event
handler->event(handle, type, code, value); //这里最终就是调用 evdev_event 唤醒 evdev_read函数唤醒后调用 input_event_to_user 把数据给app
到这里框架就分析完毕了，那么 我们自已如何编写一个符合内核这套input 输入子系统的驱动呢，我们主要关心设备层
1：分配一个input_dev 结构体
2：设置
3：注册
4：硬件机关的操作 （例：当按键按下中，产生中断，在中断服务函数里上报事件即可）
原文地址：https://www.cnblogs.com/x2i0e19linux/p/11730488.html