www.ourkernel.com 我们的内核
u32 intf_num;
};
int interface_add_data(struct interface_data *);
该接口是负责分配并初始化一种结构intf_data，并调用interface_add_data()将其添加到他所属于的设备接口清单中。当设备从类中注销时该清单会被更新（而不是一个类中所有可能的接口（发生改变））。这种结构或许应该根植于无论何种的单一设备数据结构，无论接口是如何分配的。
枚举设备的接口。其发生在interface_add_data()和枚举值中，存放在设备的结构intf_data。
sysfs
～～～～～
在其所属的设备类的目录中，每一种接口都给定一索引： 在class目录中，接口同时得到一个索引： class/ `-- input
|-- devices |-- drivers |-- mouse
`-- evdev
当一个设备加入到接口中，便形成了一个指向物理层中设备目录的符号链接。 class/
`-- input
|-- devices
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/ |-- drivers
| `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/ |-- mouse
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/ `-- evdev
`-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
未来计划
～～～～～～
一种设备接口直接与一个用户空间的接口相连，（一种特殊的设备节点。）比如说，一个SCSI磁盘提供了至少两个用户空间的接口：标准的SCSI磁盘接口和一般的SCSI接口。他可能也会使用一个更加原始设备接口。
许多接口都具有一个主设备号，该接口下的每个设备都有一个次设备号。 在特殊情况下，几个接口共用一个主设备号，分别使用不同区间的从设备号（比如说是输入设备）。
我们可以将主设备号和次设备号保存在interface结构体中。在接口向class注册时，将分配主设备号和次设备号。我们也可以使用一个内核函数来完成主次设备号的分配。
29
www.ourkernel.com 我们的内核
Platform
原文作者：
翻 译者： Solarapex solarapex.hxf@gmail.com 校 订者：
版本状态：还未完成
======================================
平台设备和驱动
~~~~~~~~~~~~
在
这样的总线包括许多片上系统上的那些用来整合外设的总线, 也包括一些\古董\上的连接器; 但不包
括像PCI或USB这样的有庞大正规说明的总线.
平台设备
~~~~~~
平台设备通常指的是系统中的自治体, 包括老式的基于端口的设备和连接外设总线的北桥(host bridges),
以及集成在片上系统中的绝大多数控制器. 它们通常拥有的一个共同特征是直接编址于CPU总线上. 即使在某
些罕见的情况下, 平台设备会通过某段其他类型的总线连入系统, 它们的寄存器也会被直接编址.
平台设备会分到一个名称(用在驱动绑定中)以及一系列诸如地址和中断请求号(IRQ)之类的资源.
struct platform_device { const char *name;
u32 id;
struct device dev;
u32 num_resources; struct resource *resource; };
平台驱动
~~~~~~
平台驱动遵循标准驱动模型的规范, 也就是说发现/列举(discovery/enumeration)在驱动之外处理, 而
由驱动提供probe()和remove方法. 平台驱动按标准规范对电源管理和关机通告提供支持.
struct platform_driver {
30
www.ourkernel.com 我们的内核
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 (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *);
struct device_driver driver; };
注意probe()总应该核实指定的设备硬件确实存在;平台设置代码有时不能确定这一点. 枚举(probing)
可以使用的设备资源包括时钟及设备的platform_data.
(译注: platform_data定义在device.txt中的\基本设备结构体\中.)
平台驱动通过普通的方法注册自身:
int platform_driver_register(struct platform_driver *drv);
或者, 更常见的情况是已知设备不可热插拔, probe()过程便可以驻留在一个初始化区域(init section)
中,以便减少驱动的运行时内存占用(memory footprint):
int platform_driver_probe(struct platform_driver *drv, int (*probe)(struct platform_device *))
设备列举
~~~~~~~
按规定, 应由针对平台(也适用于针对板)的设置代码来注册平台设备:
int platform_device_register(struct platform_device *pdev);
int platform_add_devices(struct platform_device **pdevs, int ndev);
一般的规则是只注册那些实际存在的设备, 但也有例外. 例如, 某外部网卡未必会装配在所有的板子上,
或者某集成控制器所在的板上可能没挂任何外设, 而内核却需要被配置来支持这些网卡和控制器.
有些情况下, 启动固件(boot firmware)会导出一张装配到板上的设备的描述表. 如果没有这张表, 通常
就只能通过编译针对目标板的内核来让系统设置代码安装正确的设备了. 这种针对板的内核在嵌入式和自定
义的系统开发中是比较常见的.
31
www.ourkernel.com 我们的内核
多数情况下, 分给平台设备的内存和中断请求号资源是不足以让设备正常工作的. 板设置代码通常会用设备
的platform_data域来存放附加信息, 并向外提供它们.
嵌入式系统时常需要为平台设备提供一个或多个时钟信号. 除非被用到, 这些时钟一般处于静息状态以节电.
系统设置代码也负责为设备提供这些时钟, 以便设备能在它们需要是调用 clk_get(&pdev->dev, clock_name).
老式驱动: 设备枚举
~~~~~~~~~~~~~~~~
有些驱动不能被彻底归入驱动模型, 因为它们承担了一个应该由系统基本组建来完成的任务:注册平台设备.
因为热插拔和冷插拔要求由非驱动程序的系统组件来创建设备,所以上述驱动不支持这两种机制.
保留这些驱动的唯一\恰当\的理由是要用它们应付老式的系统设计, 比如原始的IBM PC就依赖一种容易出错
的\枚举硬件(probe-the-hardware)\模型来配置硬件. 新的系统基本上废弃了这种模型, 而倾向对动态
配置的总线级支持(PCI, USB), 或是由启动固件来提供设备描述表(例如x86上的PNPACPI). 关于什么东西
出现在哪儿有太多冲突的可能,即使由操作系统来做有根据的猜测, 也难免因频繁出错而惹麻烦.
(译注: Understanding the Linux Kernel一书的第13.1.1.1节, 提到了\枚举硬件\其中的一段或许
可以用来解释最后一句中所谓的\冲突\ 尽管访问I/O端口很容易, 检测哪个I/O端口已被分配给I/O设备却并非易事. 对基于ISA总线 (译注:原始IBM PC采用的总线)的系统来说尤其如此. 通常设备驱动必须盲目地写数据到一些 I/O端口来探测设备的存在, 然而,如果该端口已经被另外一种设备占用, 这样的操作就可能导 致系统崩溃...
不提倡这种驱动方式. 假如你在升级这样一个驱动, 请尽力把设备列举从驱动中转移到更合适的地方. 这样
做很赚, 因为驱动程序一开始就处在\正常模式\可以直接使用由即插即用(PNP)设置或平台设备设置代码 所创建的设备..
struct platform_device *platform_device_alloc(
32