学习笔记 --- LINUX虚拟总线分析

LINUX 内核里面有很多总线：USB ，SPI，IIC，PCI总线，虚拟总线，这些总线在LINUX内核里面建立起了一个抽象的模型，看下这个模型的大体结构：

LINUX所有总线都是用这个框架，一边是设备，一边是驱动，无论是添加设备（device_add）还是添加驱动(driver_register)，都会调用march函数去匹配设备对应的驱动或者驱动对应的设备，匹配完后就调用设备驱动的probe函数，进入设备驱动入口。这个模型的大体流程就是这样，不同的总线操作用不同的bus_type来表示。我们这里要说的是虚拟总线：

struct bus_type platform_bus_type = {
	.name		= "platform",
	.dev_attrs	= platform_dev_attrs,
	.match		= platform_match,
	.uevent		= platform_uevent,
	.pm		= &platform_dev_pm_ops,
};

虚拟总线的match函数是比较device和driver的name，如果相同就匹配上，匹配OK后就注册驱动了：

static int platform_match(struct device *dev, struct device_driver *drv)
{
	struct platform_device *pdev = to_platform_device(dev);
	struct platform_driver *pdrv = to_platform_driver(drv);

	/* match against the id table first */
	if (pdrv->id_table)
		return platform_match_id(pdrv->id_table, pdev) != NULL;

	/* fall-back to driver name match */
	return (strcmp(pdev->name, drv->name) == 0); //匹配
}

上面的匹配函数在__driver_attach或__drive_attach里面，这两个注册驱动会调用__driver_attach，注册设备会调用__drive_attach。

注册驱动时的函数调用路径：platform_driver_register - driver_register- bus_add_driver- driver_attach- bus_for_each_dev - __driver_attach

注册设备时的函数调用路径：platform_device_register - platform_device_add - device_add - bus_probe_device - device_attach - bus_for_each_drv - __device_attach

注册驱动时：

static int __driver_attach(struct device *dev, void *data)
{
	struct device_driver *drv = data;


	/*
	 * Lock device and try to bind to it. We drop the error
	 * here and always return 0, because we need to keep trying
	 * to bind to devices and some drivers will return an error
	 * simply if it didn't support the device.
	 *
	 * driver_probe_device() will spit a warning if there
	 * is an error.
	 */


	if (!driver_match_device(drv, dev))  //匹配
		return 0;


	if (dev->parent)	/* Needed for USB */
		down(&dev->parent->sem);
	down(&dev->sem);
	if (!dev->driver)
		driver_probe_device(drv, dev);  //匹配成功则调用probe
	up(&dev->sem);
	if (dev->parent)
		up(&dev->parent->sem);


	return 0;
}

注册设备时：

static int __device_attach(struct device_driver *drv, void *data)
{
	struct device *dev = data;

	if (!driver_match_device(drv, dev)) //匹配
		return 0;

	return driver_probe_device(drv, dev); //调用probe
}

所以无论注册驱动还是设备都会匹配一次对方，再probe。这跟输入子系统的device和handler的处理机制一样，他们也是去匹配，匹配后再connect。

这里driver_probe_device调用的就是driver里面的probe：

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;
	struct platform_device_id *id_table;
};

下面以LED为例，先看device代码：

#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, //GPIO配置寄存器物理地址
        .end   = 0x56000050 + 8 - 1, 
        .flags = IORESOURCE_MEM,  //表示是内存资源，使用的时候需要ioremap把物理地址转化成虚拟地址
    },
    [1] = {
        .start = 5,  //GPIO口
        .end   = 5,
        .flags = IORESOURCE_IRQ,   //表示是中断资源，这个只是个标志而已，只要driver端认得就可以，我们这里随便设置为中断类型的
    }

};

static void led_release(struct device * dev) 
{
    
}

static struct platform_device led_dev = {
    .name         = "myled", //这里的设备名要和driver的名相同
    .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");

上面可以知道device代码就是定义名字和一些资源，然后注册platform的device。他的主要目的就是向driver（驱动）提供硬件资源。

再看driver代码：

#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");

上面可以看出driver的主要任务就是获取device提供的资源，使用这些资源。然后其他的就和普通的驱动差不多，只是硬件资料从device资源获得的。
一个LED的驱动很简单，不需要这么麻烦，只是提高了软件的架构稳固性和驱动统一性，功能实现起来都是一样的效果。测试：

#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            则灯灭*/

上面分析了device端通过资源结构体传递资源给driver端，如果遇到更加复杂的信息怎么传递?看下这个device端的结构体:

struct platform_device {
	const char	* name;
	int		id;
	struct device	dev; //复杂的资源通过dev里面的platform_data传递
	u32		num_resources;
	struct resource	* resource; //简单的资源通过这个传递

	struct platform_device_id	*id_entry;

	/* arch specific additions */
	struct pdev_archdata	archdata;
};

可以利用dev结构体里面的platform_data来传递复杂的资料，将资料的数据结构首地址传递给dev里面的platform_data