平台总线设备驱动模型——代码分析

本文深入剖析了Linux平台总线设备驱动的实现原理,包括设备注册与驱动匹配过程、字符设备注册及设备文件自动生成等内容。通过具体的代码示例展示了如何定义资源、注册平台设备与驱动,并给出测试程序说明。
节我们分析了平台总线的工作流程,这一节里我们来分析代码:
先来看设备驱动代码:
#include <linux/module.h>
#include <linux/version.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/interrupt.h>
#include <linux/list.h>
#include <linux/timer.h>
#include <linux/init.h>
#include <linux/serial_core.h>
#include <linux/platform_device.h>
/*定义资源,可以在平台总线驱动程序里通过platform_get_resource()函数来获得资源*/
static struct resource led_resource[] = {
    [0] = {
        .start = 0x56000050,
        .end   = 0x56000050 + 8 - 1,
        .flags = IORESOURCE_MEM,  //表示是内存资源,使用的时候需要ioremap的哦
    },
    [1] = {
        .start = 5,
        .end   = 5,
        .flags = IORESOURCE_IRQ,   //表示是中断资源,不用映射
    }

};

static void led_release(struct device * dev)//这个函数是必须的,但里面可以什么都不做
{
    
}

static struct platform_device led_dev = {
    .name         = "myled", //这里的设备名要和驱动里的驱动名相同的哦
    .id       = -1,
    .num_resources    = ARRAY_SIZE(led_resource),
    .resource     = led_resource,   //这里就是刚刚定义的资源
    .dev = { 
    .release = led_release,      //注册release函数,应该是platform_device_unregister的时候会调用
},
};

static int led_dev_init(void)
{
platform_device_register(&led_dev);  //注册平台设备
return 0;
}

static void led_dev_exit(void)
{
platform_device_unregister(&led_dev);
}

module_init(led_dev_init);
module_exit(led_dev_exit);
MODULE_LICENSE("GPL");

再来看一下驱动代码:
#include <linux/module.h>
#include <linux/version.h>
#include <linux/init.h>
#include <linux/fs.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/sched.h>
#include <linux/pm.h>
#include <linux/sysctl.h>
#include <linux/proc_fs.h>
#include <linux/delay.h>
#include <linux/platform_device.h>
#include <linux/input.h>
#include <linux/irq.h>
#include <asm/uaccess.h>
#include <asm/io.h>

static volatile unsigned long *gpio_con;
static volatile unsigned long *gpio_dat;
static struct class *cls;
static int major;
static int pin;
/*将引脚设置为输出引脚*/
static int  led_open(struct inode *inode, struct file *file)
{
    *gpio_con &= ~(0x3<<(pin*2));
    *gpio_con |= (0x1<<(pin*2));
    return 0;
}

/*根据用户空间里传进来的参数点亮或者熄灭led*/
static int led_write (struct file *file, const char __user *buff, size_t count, loff_t *ppos)
{
    int val;
    copy_from_user(&val, buff, count);

    if (val == 0)
{
*gpio_dat &= ~(1<<pin);
}
else
{
*gpio_dat |= (1<<pin);
}
return 0;
}

static struct file_operations led_fops={
    .owner  =   THIS_MODULE, 
    .open   =   led_open,
    .write = led_write,
};
/*主要的工作放在了这个地方*/
static int led_probe(struct platform_device *pdev)//匹配之后会将设备作为参数传进来的哦
{
    struct resource *res;
    res=platform_get_resource(pdev, IORESOURCE_MEM, 0);//获取设备里定义的内存资源
    gpio_con = ioremap(res->start, res->end - res->start + 1);//内存资源需要映射的哦
    gpio_dat = gpio_con + 1;

    res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);//获取设备里定义的中断资源,这里其实只是一个引脚而已
    pin = res->start;
    printk("led_probe, found led\n");
    major=register_chrdev(0, "myled", &led_fops);  //注册字符设备,那么下面肯定重点放在了file_operations结构体上了
    cls = class_create(THIS_MODULE, "myled");     //创建类
    class_device_create(cls, NULL, MKDEV(major, 0), NULL, "led");//类下创建设备,这样保证了udev机制可以自动创建设备文件
    return 0;
    
}
/*与分析相一致,卸载函数放在了这里*/
static int led_remove(struct platform_device *pdev)
{
    printk("led_remove, remove led\n");
    class_device_destroy(cls, MKDEV(major, 0));
    class_destroy(cls);
    unregister_chrdev(major, "myled");
    iounmap(gpio_con);
    return 0;
}
/*定义platform_driver 结构体*/
struct platform_driver led_drv = {
.probe = led_probe,  //这里是probe函数,当总线发现有设备的名字和驱动的名字相同时会调用这个函数,所以我们的主要工作放在了这里面
.remove = led_remove,  //这个函数应该是在platform_driver_unregister是调用用,因此可以将一些卸载函数放在这个地方
.driver = {
.name = "myled",    //这名字要和设备相匹配的哦
}
};

static int led_drv_init(void)
{
platform_driver_register(&led_drv);//注册平台总线驱动,里面有比较重要的platform_driver 结构体
return 0;
}

static void led_drv_exit(void)
{
platform_driver_unregister(&led_drv);
}

module_init(led_drv_init);
module_exit(led_drv_exit);
MODULE_LICENSE("GPL");

下面再来看看测试程序:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>

int main(int argc, char **argv)
{
int fd;
int val = 1;
fd = open("/dev/led", O_RDWR);
if (fd < 0)
{
printf("can't open!\n");
}
if (argc != 2)
{
printf("Usage :\n");
printf("%s <on|off>\n", argv[0]);
return 0;
}

if (strcmp(argv[1], "on") == 0)
{
val  = 1;
}
else
{
val = 0;
}
write(fd, &val, 4);
return 0;
}

测试方法:假设测试程序编译出来后名字是ledtest
我们在命令行输入:./ledtest /dev/led on            则灯亮
                       输入:./ledtest /dev/led/off            则灯灭

我们来总结一下这三个程序的原理:
比如我们先注册了设备,这时总线会遍历驱动,寻找可以匹配该设备的驱动。由于我们还没有注册驱动,所以这时候不会发生什么事情。接着我们注册了驱动,这时会去遍历设备,这时因为设备已经注册了,所以会找到匹配项,这时将调用驱动中的probe函数,在这个函数里完成了字符设备的注册,以及设备文件的自动生成。然后运行我们的测试程序就可以对字符设备进行操作了。
那我们想想这种机制有什么好处呢?其实这就是采用了一种分离的机制,将设备和驱动分开,当我们想操作其它设备的时候,只需要修改设备文件就可以了!比如我们想操作其它的led,那么只需将设备文件里的资源改掉就可以了,并不需要修改驱动文件。这就为一只提供了很大的方面,后面会深有体会的哦!
【重要提示】本资源设置为0积分下载,若非0积分请勿轻易下载 亲爱的CSDN用户: 首先感谢你点进这个资源页面。我需要提前说明一个重要情况: 本资源原本已设置为“0积分下载”,即作者希望完全免费共享。但CSDN平台有时会根据文件的下载热度、文件大小、用户权限等因素,自动将部分资源的积分调整为非0数值(如1积分、2积分、5积分等)。这是平台系统的自动行为,而非作者本人的设定。 因此,如果你当前看到该资源的下载所需积分不是0(例如显示为1、2、3……),请谨慎决定是否下载。 如果你按照非0积分支付并下载后发现资源内容不符合预期、链接失效,或者实际上该资源本应是免费的,作者无法为此承担积分损失或退还操作。强烈建议:仅在页面显示为0积分时进行下载。 另外,本资源描述中并未直接提供具体的下载地址或外部链接,因为它本身是一个通过CSDN官方上传通道提交的文件/内容包。如果你看到描述中没有外部网盘地址,这是正常的——资源文件应通过CSDN内置的“下载”按钮获取。若因平台积分显示异常导致你支付了积分,请优先联系CSDN客服咨询积分退还政策,作者没有权限修改平台自动设定的积分值。 感谢你的理解与支持。技术分享本应开放,但受限于平台规则,特此提醒如上。祝学习进步!
源码下载地址: https://pan.quark.cn/s/a4b39357ea24 MAC(媒体访问控制器)与PHY(物理接口收发器)是构成以太网基础架构的两个核心组成部分,它们在数据链路层和物理层中承担着重要功能。以太网技术是计算机网络领域中应用最为广泛的局域网技术之一,其相关标准主要由IEEE通过IEEE 802.3标准来制定,该标准详细规定了从物理层到介质访问控制层的通信协议和规范。MAC主要负责数据链路层的下半部分功能,其核心职责包括对网络中的数据传输进行管理,确保数据能够准确无误地在网络中传输。MAC通过评估网络状态来决定是否可以发送数据,并在发送前为数据附加必要的控制信息,最终将数据和控制信息按照标准格式传输至物理层。在接收数据时,MAC协议负责判断数据传输是否出现错误,若无错误则将数据的控制信息剥离后传递给逻辑链路控制(LLC)层。 PHY则负责物理层的具体实现,涵盖了电信号的传输与接收,以及将数据转换为物理信号发送至网络,或将物理信号转换回数据供MAC处理。IEEE 802.3标准对PHY的规范进行了规定,不同速度的PHY,例如10BaseT和100BaseTX,虽然在物理层上具有相同的分组描述,但所采用的信令机制存在差异,10BaseT使用曼彻斯特编码,而100BaseTX采用4B/5B编码,这种设计防止了硬件在不同速度下能够轻易兼容。 媒体独立接口(MII)是用于连接MAC和PHY的标准接口,作为IEEE 802.3定义的一个以太网行业标准,它包含了数据接口和管理接口。数据接口运用了两条独立的信道,其中一条用于发送器,另一条用于接收器,每条信道都包含数据、时钟和控制信号。总共需要16个信号来实现MII接口,以支持MAC和PHY之间的数据交...
内容概要:本文系统研究了基于交流潮流的电力系统多元件N-k故障模型,通过Matlab代码实现了在多重故障条件下电力系统潮流的精确计算与安全性分析。该模型充分考虑交流潮流的非线性特性,构建了更为精确的N-k故障数学表达形式,能够有效模拟实际电网中多个元件同时发生故障的复杂场景,从而提升对系统脆弱性的识别能力和安全评估的准确性。研究重点涵盖故障组合的高效枚举、交流潮流方程在故障状态下的修正求解方法,以及关键故障场景的筛选机制,并配套提供完整的Matlab仿真程序,便于用户复现结果、验证算法并拓展应用于其他测试系统。; 适合人群:具备电力系统分析基础理论知识和Matlab编程能力的科研人员、电气工程专业研究生,以及从事电网安全评估、可靠性分析和运行调度的工程技术人员。; 使用场景及目标:①开展电力系统多重故障下的安全性与稳定性评估;②支撑电网规划阶段的N-k安全准则校验;③用于学术研究中对连锁故障传播机理的建模与仿真分析;④识别电网中的关键薄弱环节,为提升系统韧性、制定应急控制策略和优化防护资源配置提供技术依据。; 阅读建议:建议读者结合电力系统潮流计算与稳定性相关理论,深入理解N-k故障建模的核心逻辑,重点关注交流潮流在故障注入后的处理方法,务必动手运行所提供的Matlab代码,通过调试与修改加深对算法实现细节的掌握,并尝试将其应用于IEEE标准测试系统或其他实际电网模型中进行对比验证与性能优化。
【重要提示】本资源设置为0积分下载,若非0积分请勿轻易下载 亲爱的CSDN用户: 首先感谢你点进这个资源页面。我需要提前说明一个重要情况: 本资源原本已设置为“0积分下载”,即作者希望完全免费共享。但CSDN平台有时会根据文件的下载热度、文件大小、用户权限等因素,自动将部分资源的积分调整为非0数值(如1积分、2积分、5积分等)。这是平台系统的自动行为,而非作者本人的设定。 因此,如果你当前看到该资源的下载所需积分不是0(例如显示为1、2、3……),请谨慎决定是否下载。 如果你按照非0积分支付并下载后发现资源内容不符合预期、链接失效,或者实际上该资源本应是免费的,作者无法为此承担积分损失或退还操作。强烈建议:仅在页面显示为0积分时进行下载。 另外,本资源描述中并未直接提供具体的下载地址或外部链接,因为它本身是一个通过CSDN官方上传通道提交的文件/内容包。如果你看到描述中没有外部网盘地址,这是正常的——资源文件应通过CSDN内置的“下载”按钮获取。若因平台积分显示异常导致你支付了积分,请优先联系CSDN客服咨询积分退还政策,作者没有权限修改平台自动设定的积分值。 感谢你的理解与支持。技术分享本应开放,但受限于平台规则,特此提醒如上。祝学习进步!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值