移植mini2440 2.6.32.2内核LED驱动到3.10.17

最新推荐文章于 2021-05-02 22:58:02 发布

原创最新推荐文章于 2021-05-02 22:58:02 发布 · 1k 阅读

1 ·

CC 4.0 BY-SA版权

MINI2440 专栏收录该内容

7 篇文章

订阅专栏

本文详细阐述了如何在Linux 3.10.17内核环境下，针对SBC2440 LED驱动进行优化和实现，包括解决内核函数变化导致的问题、更新GPIO配置函数及初始化过程，确保驱动与新内核的兼容性和稳定性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

#include <linux/miscdevice.h>
#include <linux/delay.h>
#include <asm/irq.h>
#include <mach/regs-gpio.h>
#include <mach/hardware.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/mm.h>
#include <linux/fs.h>
#include <linux/types.h>
#include <linux/delay.h>
#include <linux/moduleparam.h>
#include <linux/slab.h>
#include <linux/errno.h>
#include <linux/ioctl.h>
#include <linux/cdev.h>
#include <linux/string.h>
#include <linux/list.h>
#include <linux/pci.h>
#include <linux/gpio.h>
#include <asm/uaccess.h>
#include <asm/atomic.h>
#include <asm/unistd.h>

#define DEVICE_NAME "leds" //设备名(/dev/leds)
//LED 对应的GPIO 端口列表
static unsigned long led_table[] =
{
S3C2410_GPB(5),
S3C2410_GPB(6),
S3C2410_GPB(7),
S3C2410_GPB(8),
};
//LED 对应端口将要输出的状态列表
static unsigned int led_cfg_table[] = {

S3C2410_GPIO_OUTPUT,
S3C2410_GPIO_OUTPUT,
S3C2410_GPIO_OUTPUT,
S3C2410_GPIO_OUTPUT,
};

/*ioctl 函数的实现
* 在应用/用户层将通过ioctl 函数向内核传递参数，以控制LED 的输出状态
*/
static int sbc2440_leds_ioctl(
struct inode *inode,
struct file *file,
unsigned int cmd,
unsigned long arg)
{

switch(cmd) {

case 0:
case 1:
if (arg > 4)
{

return -EINVAL;
}
//根据应用/用户层传递来的参数(取反)，通过s3c2410_gpio_setpin
// 函数设置LED 对应的端口寄存器，
//s3c_gpio_setpin(led_table[arg], !cmd);
gpio_set_value(led_table[arg], !cmd);
return 0;
default:
return -EINVAL;
}
}
/*
* 设备函数操作集，在此只有ioctl 函数，通常还有read, write,
open, close 等，因为本LED 驱动在下面已经
* 注册为misc 设备，因此也可以不用open/close
*/
static struct file_operations dev_fops = {

.owner = THIS_MODULE,
.ioctl = sbc2440_leds_ioctl,
};
/*
* 把LED 驱动注册为MISC 设备
*/
static struct miscdevice misc = {

.minor = MISC_DYNAMIC_MINOR, //动态设备号
.name = DEVICE_NAME,
.fops = &dev_fops,
};
/*
* 设备初始化
*/
static int __init dev_init(void)
{

int ret;
int i;
for (i = 0; i < 4; i++) {

//设置LED 对应的端口寄存器为输出(OUTPUT)
s3c2410_gpio_cfgpin(led_table[i], led_cfg_table[i]);
//设置LED
// 对应的端口寄存器为低电平输出，在模块加载结束后，四个LED
// 应该是全部都是发光
// //状态
s3c2410_gpio_setpin(led_table[i], 0);
}
ret = misc_register(&misc); //注册设备
printk (DEVICE_NAME"\tinitialized\n");
//打印初始化信息
return ret;
}
static void __exit dev_exit(void)
{
misc_deregister(&misc);
}
module_init(dev_init);
//模块初始化，仅当使用insmod/podprobe
//命令加载时有用，如果设备不是通过模块方式加载，此处将不会被调用
module_exit(dev_exit);//卸载模块，当该设备通过模块方式加载后，可以通过rmmod
// 命令卸载，将调用此函数
MODULE_LICENSE("GPL"); //版权信息
MODULE_AUTHOR("RenZhe gzs"); //开发者信息

Makefile文件：

KDIR = /work/src/linux-2.6.32.2/
appgcc = /work/toolschain/arm-2013.05/bin/arm-none-linux-gnueabi-gcc
obj-m := led.o

all:
make -C $(KDIR) M=$(PWD)
sudo cp led.ko /work/nfs/root/root#编译后复制到nfs

clean:
make -C $(KDIR) M=$(PWD) clean

源码已经在2.6内核编译通过，修改Makefile文件后编译

make -C /work/src/linux-3.10.17/ M=/work/drivers/arm_led
make[1]: 正在进入目录 `/work/src/linux-3.10.17'
LD /work/drivers/arm_led/built-in.o
CC [M] /work/drivers/arm_led/led.o
/work/drivers/arm_led/led.c:80: error: unknown field 'ioctl' specified in initializer
/work/drivers/arm_led/led.c:80: warning: initialization from incompatible pointer type
/work/drivers/arm_led/led.c: In function 'dev_init':
/work/drivers/arm_led/led.c:102: error: implicit declaration of function 's3c2410_gpio_cfgpin'
/work/drivers/arm_led/led.c:107: error: implicit declaration of function 's3c2410_gpio_setpin'
make[2]: *** [/work/drivers/arm_led/led.o] 错误 1
make[1]: *** [_module_/work/drivers/arm_led] 错误 2
make[1]:正在离开目录 `/work/src/linux-3.10.17'
make: *** [all] 错误 2

原因是：在3.10.17内核上file_operations发生了重大的改变：

原先的

　　int (*ioctl)(struct inode*, struct file*, unsigned int, unsigned long);

被改为了

　　　long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);

因而在实际驱动中，我们需要将原先的写的ioctl函数头给改成下面的unlocked_ioctl，在file_operations结构体的填充中也是一样。

error: unknown field 'ioctl' specified in initializer问题是由于3.10.17内核之后去掉了原来的ioctl，添加两个新的成员，所以会出错

long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);

long (*compat_ioctl) (struct file *, unsigned int, unsigned long);

所以修改源文件中file_operations内.ioctl 改为 .compat_ioctl 即可

至于警告是因为参数减少了一个，去掉即可

用cgvg查找3.10内核目录发现没有（设置IO口为输出）s3c2410_gpio_cfgpin这个函数，对照/drivers/leds/leds-s3c24xx.c这个驱动文件发现设置输出的函数改为了gpio_direction_output函数原型为gpio_direction_output(unisgned gpio, int value);第一个参数为GPIO，第二个为新gpio_set_value（port_num,0/1）值gpio_set_value（port_num,0/1）

s3c2410_gpio_setpin对应函数gpio_set_value（port_num,0/1）设置新状态

以下是转载内容：

在kernel 2.6.36 中已经完全删除了struct file_operations 中的ioctl 函数指针，取而代之的是unlocked_ioctl 。

这个指针函数变了之后最大的影响是参数中少了inode ，不过这个不是问题，因为用户程序中的ioctl对应的系统调用接口没有变化，所以用户程序不需要改变，一切都交给内核处理了，如果想在unlocked_ioctl中获得inode 等信息可以用如下方法：

struct inode *inode = file->f_mapping->host;

struct block_device *bdev = inode->i_bdev;

struct gendisk *disk = bdev->bd_disk;

fmode_t mode = file->f_mode;

struct backing_dev_info *bdi;

这次内核函数的变化引出了一个问题，从ioctl系统调用往后，真正的ioctl调用顺序是什么？为什么compat_ioctl 不被调用？

compat_ioctl被使用在用户空间为32位模式，而内核运行在64位模式时。这时候，需要将64位转成32位。

以下是2.6.36的情况：

SYSCALL_DEFINE3(ioctl ...)    compat_sys_ioctl  (是否直接调用compat_ioctl 取决于compat_ioctl 是否存在)
        |                        |        |-----> compat_ioctl
        |                        |
        |------>do_vfs_ioctl (下一步的调用取决于file->f_path.dentry->d_inode->i_node)
        |            |------>file_ioctl
        |                       |
        |-------------------------------->vfs_ioctl
                                              |------->unlock_ioctl

其实compat_ioctl 没有被调用的原因是compat_sys_ioctl 没有被调用，而它没有被调用的原因似乎是压根就没有编译到内核中，因为我没有找到调用这个函数的代码。

unlocked_ioctl 实际上取代了用了很久的ioctl，主要的改进就是不再需要上大内核锁（调用之前不再先调用lock_kernel()然后再unlock_kernel()）

总的来说kernel 开发者正在试图朝移除大内核锁的方向努力，ioctl的移除就是被革命了。相信以后越来越多的内核函数会摆脱大内核锁的依赖，并且大内核锁最终会被移除。

（以上内容为转载）