探究platform_driver中“多态”思想

问题最初是下面的两段代码引出的:

static struct platform_driver sonypi_driver = {
    .driver        = {
        .name    = "sonypi",
        .owner    = THIS_MODULE,
    },
    .probe        = sonypi_probe,
    .remove        = __devexit_p(sonypi_remove),
    .shutdown    = sonypi_shutdown,
    .suspend    = sonypi_suspend,
    .resume        = sonypi_resume,
};
static const struct dev_pm_ops aa5302_pm_ops = {
    .suspend    = aa5302_suspend,
    .resume        = aa5302_resume,
};
#endif

static struct platform_driver aa5302_driver = {
    .driver = {
        .name  = "aa5302",
        .owner = THIS_MODULE,
#ifdef CONFIG_PM
        .pm    = &aa5302_pm_ops,
#endif
    },
    .probe = aa5302_probe,
    .remove = __devexit_p(aa5302_remove),
    .shutdown = aa5302_shutdown,
};

注意到这两个驱动都是platform driver,但是对于电源管理的定义方式却不同:前者直接赋值platform_driver中的suspend/resume字段,后者间接赋值driver.pm字段。一直以来,我接触到的原厂驱动,大部分是后面的定义方式,一直觉得其定义方式很罗嗦,这次要好好研究一下。

这里http://lists.kernelnewbies.org/pipermail/kernelnewbies/2013-October/009074.html有人问了一个类似的问题,可惜的是没有回复!

我们先看看kernel/include/linux/platform_device.h中的定义:

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

再看看kernel/include/linux/device.h中的定义:

struct device_driver {
    const char        *name;
    struct bus_type        *bus;
    struct module        *owner;
    const char        *mod_name;    /* used for built-in modules */
    bool suppress_bind_attrs;    /* disables bind/unbind via sysfs */
    const struct of_device_id    *of_match_table;
    int (*probe) (struct device *dev);
    int (*remove) (struct device *dev);
    void (*shutdown) (struct device *dev);
    int (*suspend) (struct device *dev, pm_message_t state);
    int (*resume) (struct device *dev);
    const struct attribute_group **groups;
    const struct dev_pm_ops *pm;
    struct driver_private *p;
};

初看,它们都定义了probe, remove ... 等函数,但platform_driver里面包含了device_driver结构体,也就是说platform_driver中实际上有2套probe, remove ... 为什么会这样的?我们再看看drivers/base/platform.c中关于platform_driver_register的定义:

int platform_driver_register(struct platform_driver *drv)
{
    drv->driver.bus = &platform_bus_type;
    if (drv->probe)
        drv->driver.probe = platform_drv_probe;
    if (drv->remove)
        drv->driver.remove = platform_drv_remove;
    if (drv->shutdown)
        drv->driver.shutdown = platform_drv_shutdown;

    return driver_register(&drv->driver);
}

至此,你可能会更纳闷,这不是画蛇添足吗?把platform_driver中的probe, remove字段又赋值给了driver中的相应字段,最终效果是,这2套probe, remove...实际上指向的分别是相同的回调函数!其实,如果细看platform_driver和device_driver中的probe, remove指针的定义,你会发现,他们还是有差别的:

int (*probe)(struct platform_device *);
int (*probe) (struct device *dev);

那就是,参数类型不同哦!前者是platform_device,后者是device!如果你学习过C++语言,头脑中有“继承”和“多态”的概念,我相信你已经知道为什么要这么做了:)

这么说吧,device和device_driver分别是驱动中的基类,而platform_device和platform_driver分别是PLATFORM BUS体系中对应的派生类;device_driver中的probe是基类的虚函数,platform_driver中的probe是派生类中的重载函数。如果我们要写的是platform设备驱动,那么应该按照platform_driver中的回调函数声明格式来定义自己的回调函数。

因此sonypi驱动的shutdown函数是这样定义的:

static void sonypi_shutdown(struct platform_device *dev)
{
    sonypi_disable();
}

而不是:

static void sonypi_shutdown(struct device *dev)
{
    sonypi_disable();
}

如果你非要用这个“基类的函数”,那也是有办法的,在声明platform_driver的时候,用下面的方式,纯属猜测,没有验证哈。

static struct platform_driver sonypi_driver = {
    .driver        = {
        .name    = "sonypi",
        .owner    = THIS_MODULE,
        .shutdown = sonypi_shutdown,
    },
    .probe        = sonypi_probe,
    .remove        = __devexit_p(sonypi_remove),
    .suspend    = sonypi_suspend,
    .resume        = sonypi_resume,
};

---------------------------------------------------------华丽的分割线-----------------------------------------------------------

下面再说说电源管理的问题,sonypi驱动使用了platform_driver.suspend/resume的方式来定义回调函数,而aa5302驱动使用platform_driver.driver.pm.suspend/resume的方式定义回调,这和上面说所讲的“多态”似乎不完全契合。确实如此,这里涉及到另外一个legacy的问题,stackoverflow上的一篇解释说的很明白:http://stackoverflow.com/questions/19462639/which-suspend-resume-pointer-is-the-right-one-to-use 我们看看platform_pm_suspend的实现,如果driver.pm字段不为空,则使用.pm提供的回调,否则使用platform_driver.suspend定义的lagacy方式的回调。

int platform_pm_suspend(struct device *dev)
{
    struct device_driver *drv = dev->driver;
    int ret = 0;

    if (!drv)
        return 0;

    if (drv->pm) {
        if (drv->pm->suspend)
            ret = drv->pm->suspend(dev);
    } else {
        ret = platform_legacy_suspend(dev, PMSG_SUSPEND);
    }

    return ret;
}

device_driver.suspend/resume是旧的方式,他们在dev_pm_ops诞生以前就存在了,我们新的驱动中应该使用dev_pm_ops来定义回调函数。stackoverflow中提到的i2c驱动,跟这里的2个platform_driver还不完全一样,i2c_driver仅仅提供一组通信接口,其并不提供设备的控制逻辑,在音频codec中体现的非常明显,音频codec本质上是一个I2C芯片,在probe函数中注册了一个更加“高级”的控制设备:codec,控制逻辑由codec来完成。因此其i2c_driver中并没有提供电源管理功能:

static struct i2c_driver wm8900_i2c_driver = {
    .driver = {
        .name = "WM8900",
        .owner = THIS_MODULE,
    },
    .probe = wm8900_i2c_probe,
    .remove = __devexit_p(wm8900_i2c_remove),
    .shutdown = wm8900_i2c_shutdown,
    .id_table = wm8900_i2c_id,
};

而是转移到了codec中:

static struct snd_soc_codec_driver soc_codec_dev_wm8900 = {
    .probe =    wm8900_probe,
    .remove =    wm8900_remove,
    .suspend =    wm8900_suspend,
    .resume =    wm8900_resume,
    .set_bias_level = wm8900_set_bias_level,
    .volatile_register = wm8900_volatile_register,
    .reg_cache_size = ARRAY_SIZE(wm8900_reg_defaults),
    .reg_word_size = sizeof(u16),
    .reg_cache_default = wm8900_reg_defaults,
};
时间: 2024-10-24 10:37:07

探究platform_driver中“多态”思想的相关文章

探究platform_driver中的shutdown用途

http://blog.csdn.net/moxiaomomo/article/details/7897943 "quiesce" 说的也不太明确,我的猜测是:比如系统中有一个大功率的设备,在"软关机"的时候,会调用这个函数,可以在这个函数中切断这个设备的电源,从而省电.因为软关机后,机器本身是还有电的,并没有拔电源. shutdown: 彻底关电 suspend:休眠,可能是低功耗状态 resume:唤醒 --

C#语言基础知识(2):C#中多态

我的理解是:通过继承实现的不同对象调用相同的方法,表现出不同的行为,称之为多态. 1: OverRide 实现多态 1 public class Animal 2 { 3 public virtual void Eat() 4 { 5 Console.WriteLine("Animal eat"); 6 } 7 } 8 public class Dog : Animal 9 { 10 public override void Eat() 11 { 12 Console.WriteLin

Java编程之Map中分拣思想。

题目:给定一个字符串,求出字符串中每一个单词在字符串中出现的次数 旨意:map的分拣思想. 每一个key的包装类,存放出现的次数 1 /** 2 * 作为包装类,用来存放英文单词,和该英文单词出现的次数 3 * @ClassName: Str 4 * @Description: TODO(这里用一句话描述这个类的作用) 5 * @author 尚晓飞 6 * @date 2014-7-30 下午6:57:29 7 * 8 */ 9 public class Str { 10 private St

Java中多态的一些简单理解

什么是多态 1.面向对象的三大特性:封装.继承.多态.从一定角度来看,封装和继承几乎都是为多态而准备的.这是我们最后一个概念,也是最重要的知识点. 2.多态的定义:指允许不同类的对象对同一消息做出响应.即同一消息可以根据发送对象的不同而采用多种不同的行为方式.(发送消息就是函数调用) 3.实现多态的技术称为:动态绑定(dynamic binding),是指在执行期间判断所引用对象的实际类型,根据其实际的类型调用其相应的方法. 4.多态的作用:消除类型之间的耦合关系. 5.现实中,关于多态的例子不

[译] 探究 Swift 中的 Futures & Promises

原文地址:Under the hood of Futures & Promises in Swift 原文作者:John Sundell 译者:oOatuo 校对者:Kangkang, Richard_Lee 探究 Swift 中的 Futures & Promises 异步编程可以说是构建大多数应用程序最困难的部分之一.无论是处理后台任务,例如网络请求,在多个线程中并行执行重操作,还是延迟执行代码,这些任务往往会中断,并使我们很难调试问题. 正因为如此,许多解决方案都是为了解决上述问题而

个人对Java中多态的一些简单理解

什么是多态 面向对象的三大特性:封装.继承.多态.从一定角度来看,封装和继承几乎都是为多态而准备的.这是我们最后一个概念,也是最重要的知识点. 多态的定义:指允许不同类的对象对同一消息做出响应.即同一消息可以根据发送对象的不同而采用多种不同的行为方式.(发送消息就是函数调用) 实现多态的技术称为:动态绑定(dynamic binding),是指在执行期间判断所引用对象的实际类型,根据其实际的类型调用其相应的方法. 多态的作用:消除类型之间的耦合关系. 现实中,关于多态的例子不胜枚举. 下面是多态

探究Java中Map类

Map以按键/数值对的形式存储数据,和数组非常相似,在数组中存在的索引,它们本身也是对象.       Map的接口       Map---实现Map       Map.Entry--Map的内部类,描述Map中的按键/数值对.       SortedMap---扩展Map,使按键保持升序排列           关于怎么使用,一般是选择Map的子类,而不直接用Map类.       下面以HashMap为例.       public     static     void     ma

C++中多态

C++中多态的实现原理 当类中声明虚函数时,编译器会在类中生成一个虚函数表 虚函数表是一个存储类成员函数指针的数据结构 虚函数表是由编译器自动生成与维护的 virtual成员函数会被编译器放入虚函数表中 存在虚函数时,每个对象中都有一个指向虚函数表的指针(vptr指针) C++内存模型中,会将对象中的成员变量和成员方法分开存储,同时在成员函数中第一个参数的位置添加一个this指针. 类对象中的普通成员变量,struct变量具有相同的内存布局和字节对齐方式. 类对象中的静态成员变量,存储在全局数据

C#中多态、重载、重写区别分析

本文实例总结了C#中多态.重载与重写的概念与区别.对于初学C#的朋友来说有不错的参考价值.分享给大家供大家参考.具体分析如下: 重写 : 是指重写基类的方法,在基类中的方法必须有修饰符virtual,而在子类的方法中必须指明override . 格式如下: 1.在基类中: public virtual void myMethod() { } 2.在子类中: public override void myMethod() { } 重写以后,用基类对象和子类对象访问myMethod()方法,结果都是