嵌入式Linux 开发经验：platform_driver_register 的使用方法

it潮人

已于 2024-09-30 14:23:07 修改

阅读量247

点赞数

分类专栏：转载记录 linux 文章标签： linux

于 2024-09-30 14:07:26 首次发布

原文链接：https://blog.csdn.net/tcjy1000/article/details/128154708

版权

转载记录同时被 2 个专栏收录

387 篇文章 18 订阅

订阅专栏

linux

111 篇文章 10 订阅

订阅专栏

前言

嵌入式Linux 设备驱动开发时，经常遇到平台驱动 platform_driver_register 的注册，最近深入了看了驱动开发为何使用平台驱动
开发一个设备驱动时，为了实现设备的打开、关闭、控制等操作，可以注册为 Linux misc 设备，不过在这之前，可以先使用 platform_driver_register 注册平台驱动，在平台驱动 probe 函数中，初始化调用 misc 设备的注册操作
platform driver 在设备驱动开发中，到底起到了什么作用？为何不直接注册一个实际的设备，如 misc 【字符设备】？

Linux 驱动模型

仔细研究了一下，发现当前较新的Linux 内核版本，使用了【设备树】，这里注册的不是平台设备，而是平台的驱动，好处就是平台驱动在注册时，会自动匹配设备节点，匹配成功后，就会调用用户注册平台驱动时的 probe函数，匹配失败，就不会调用 probe函数。
利用平台驱动的这个机制，在设备匹配成功再去注册设备，那么注册实际的设备的操作放在平台驱动 probe 中调用，再适合不过了，如根据设备树觉得是否需要注册一个 misc 字符设备，如果匹配失败，那这个设备不存在，就无须注册，匹配成功，说明设备存在，就会在 probe 中注册设备。
如果只是为了匹配设备树，自己写个 match 函数就可以吧，为何还要注册平台驱动这么麻烦？其实平台驱动本身一点都不麻烦，相反如果自己去拿个【设备节点名称】去匹配设备树，才会比较的麻烦，也就是说，注册了平台驱动，这个匹配操作就自动完成了，不需要用户写一些匹配设备树的操作函数手动去匹配了。
注册了平台驱动，设备驱动如果是【模块编译】的，在移除设备驱动模块时，平台驱动remove 函数会自动调用，这样可以在 remove 函数中做些设备释放的相关操作
如此看来，注册平台驱动，简化了设备驱动的开发，交给内核驱动模型去管理设备驱动，带来了很多的便利

测试环境搭建

ubuntu 20.04
VMware Workstation Pro 16
基于qemu（模拟器），vexpress-a9 平台
Linux 6.0.10 (当前最新版本）
注册一个简单的平台驱动，掌握平台驱动注册的方法

注册Linux 平台驱动示例

在Linux 内核目录： linux-6.0.10/drivers 下创建 led_control 文件夹，当前 qemu 环境，无法控制具体的引脚，这里只作为示例，也可以实际的开发板验证
新建 linux-6.0.10/drivers/led_control/led_control.c

#include "led_control.h"

#define LED_CONTROL_DRIVER_NAME        "led_control"

static int led_control_probe(struct platform_device *pdev);
static int led_control_remove(struct platform_device *pdev);
static void led_control_shutdown(struct platform_device *pdev);

/* 设备树匹配：这里的节点，在相应的 dts 设备树文件中添加 */
static const struct of_device_id led_control_of_match[] = {
    {
        .compatible = "gpio,led,led-control",
    },
};

/* 平台驱动 ： 核心是 probe函数，设备树匹配后，会调用 probe  */
static struct platform_driver led_control_driver = {
    .probe = led_control_probe,
    .remove = led_control_remove,
    .shutdown = led_control_shutdown,
    .driver = {
        .name = LED_CONTROL_DRIVER_NAME,
        .of_match_table = of_match_ptr(led_control_of_match),
    },
};

static int led_control_probe(struct platform_device *pdev)
{
    printk(KERN_INFO "%s : enter\n", __func__);
    // led_miscdev_init();  /* 设备存在就会进入这里，注册 misc 设备 */
    return 0;
}

static int led_control_remove(struct platform_device *pdev)
{
    printk(KERN_INFO "%s : enter\n", __func__);
    //led_miscdev_exit(); /* 移除设备驱动模块时，反注册 misc 设备 */
    return 0;
}

static void led_control_shutdown(struct platform_device *pdev)
{
    printk(KERN_INFO "%s : enter\n", __func__);
}

static int __init led_control_driver_init(void)
{
    printk(KERN_INFO "%s : enter\n", __func__);
    return platform_driver_register(&led_control_driver);
}
late_initcall(led_control_driver_init); /* 自动初始化机制：开机后会调用 */

static void __exit led_control_driver_exit(void)
{
    printk(KERN_INFO "%s : enter\n", __func__);
    platform_driver_unregister(&led_control_driver);
}

module_exit(led_control_driver_exit);  /* 移除驱动模块时会调用 */

MODULE_AUTHOR("zhangsz");
MODULE_DESCRIPTION("led control driver");
MODULE_LICENSE("GPL");

新建 linux-6.0.10/drivers/led_control/led_control.h

#ifndef __LED_CONTROL_H__
#define __LED_CONTROL_H__

#include <linux/of.h>
#include <linux/platform_device.h>

//#include "led_misc.h"

#endif

新建 linux-6.0.10/drivers/led_control/Kconfig，这里增加一个【宏】

config LED_CONTROL
    tristate "Support LED Control"
    help
        Enable LED Control driver
    default y

新建 linux-6.0.10/drivers/led_control/Makefile，Linux 下，默认使用 Makefile 管理文件的编译

obj-$(CONFIG_LED_CONTROL) += led_control.o

其它修改

虽然 led_control 驱动里面Kconfig 默认选中【default y】，但是 menuconfig 中找不到这个 Kconfig 配置，需要修改 linux-6.0.10/drivers/Kconfig，把 led_control 的 Kconfig 路径添加进去

source "drivers/led_control/Kconfig"

修改二：还需修改 linux-6.0.10/drivers/Makefile，增加 led_control 的 Makefile 路径

obj-$(CONFIG_LED_CONTROL)       += led_control/

修改三：修改设备树文件 vim arch/arm/boot/dts/vexpress-v2p-ca9.dts，增加一个虚拟的设备节点

        led_control@0 {
                compatible = "gpio,led,led-control";
        };

备注：可以使用VS Code ssh 连接ubuntu 主机，进行代码的编写

编译

led_control 属于内核驱动，默认跟内核一起编译，当然也可以使用【模块编译】

编译命令：这里使用 qemu

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- vexpress_defconfig

# 默认选择了 led_control，可以 menuconfig 看看
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

## 编译，默认生成 zImage
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8

把内核编译生成的 zImage，放到 qemu 根文件系统中

启动 qemu

简单编写个启动 qemu 的shell 脚本，这样每次就不用输入那么长的命令了
vim boot_qemu.sh

#!/bin/bash
echo "---------- boot qemu ----------"
echo $1

qemu-system-arm -M vexpress-a9 -m 512M -dtb vexpress-v2p-ca9.dtb -kernel zImage -nographic -append "root=/dev/mmcblk0 rw console=ttyAMA0" -sd $1

chmod +x boot_qemu.sh 增加执行的权限
启动 qemu ，sudo ./boot_qemu.sh rootfs.ext4.img ，完整的启动命令行为

qemu-system-arm -M vexpress-a9 -m 512M -dtb vexpress-v2p-ca9.dtb -kernel zImage -nographic -append "root=/dev/mmcblk0 rw console=ttyAMA0" -sd rootfs.ext4.img

其中 rootfs.ext4.img 是根文件系统，制作方法可以参考前面的文章

ubuntu 20.04 qemu linux6.0.1 制作ext4根文件系统

启动后，发现 led_control 平台驱动注册成功，并且匹配设备树节点成功，进入了 probe 函数

led_control_driver_init : enter
led_control_probe : enter

进入 Linux shell，查看 platform 驱动的文件 ls sys/devices/platform/ -la，可以找到注册的 platform 驱动

led_control@0

reboot 时，发现调用了 led_control_shutdown : enter

以上说明 platform 驱动注册成功，调用正常

小结

Linux 的一些 misc 设备，通过先注册 platform driver 平台驱动，在平台驱动 probe 函数中再注册初始化misc 设备，这是一种很好的驱动开发设计方法，充分利用了Linux 内核提供的驱动模型带来的便利，让驱动开发精简，利于管理
Linux 设备驱动还是比较的庞大，需要花些时间与精力耐心研究，才能有所收获