ACPI规范与PNP===>Hardware ID
基于X86架构的Linux内核,在移植驱动的过程中,发现GPIO和I2C的device ID添加到pnp驱动框架后无法进入probe函数,后面找了下原因,因为pnp遵循的是ACPI规范,是由于如下Hardware ID字段是需要从BIOS中进行描述的,而目前的驱动匹配不到对应的字段,自然就不可能注册成功了。 PNP是什么东西?不是三极管的那个PNP啦,这个PNP表示的是:Plug-and-Play,译文为即插即用。 PNP的作用是自动配置底层计算机中的板卡和其他设备,然后告诉对应设备都做了什么。PnP的任务是把物理设备和软件设备驱动程序相配合,并操作设备,在每个设备和它的驱动程序之间建立通信信道。然后,PnP分配下列资源给设备和硬件:I/O地址、IRQ、DMA通道和内存段。即插即用设备配置的控制权将从系统BIOS传递到系统软件,所以驱动中一定会有代码进行描述,到时可以跟一下这部分的代码深入了解一下。由于PNP遵循ACPI的规范,那么既然是规范,那肯定要照着做了,规范怎么说,那就怎么做。 以下是关于ACPI Spec中对Hardware ID的描述,描述如下:
有关ASL语言可以参考ACPI SPEC手册的ACPI Source Language (ASL)Reference章节。如上,关于Hardware ID手册中的意思大致如下: 该对象用于向OSPM提供设备的PNP ID或ACPI ID。 在描述平台时,任何_HID对象的使用都是可选的。但是,_HID对象必须是用于描述将由OSPM枚举的任何设备。 当总线枚举器不能检测到设备ID时,OSPM只枚举一个设备。当总线枚举器不能检测到设备ID时。例如,ISA总线上的设备是由OSPM列举。除了OSPM使用_ADR对象来描述总线枚举器枚举的设备。 其中OPSM是:OSPM(OS-directed Power Management) :OSPM 操作系统支持 ACPI 的一个部分,操作系统 (OS)可以从操作系统下驱动程序的角度控制 ACPI 子模块,同时支持 ACPI 包括 SCI 中断,设备事件,系统事件模式,这些事件模式可以充分支持 Hot-plug 方式。 所以解决驱动匹配不上的问题,只要在BIOS中的ASL工程中对应Hardware描述的部分添加一个字段描述,确保驱动中的字段和BIOS中的字段一致,这样就可以匹配成功了。
接下来主要来看看在Linux内核中,内核是怎么去通过BIOS传递的参数表,传递对应的字串,然后内核又是如何来解析它,最终为Linux驱动统一模型所用。其实ARM和X86的驱动本质并没有太大的区别,都是有了一个基地址,然后依靠偏移来获取定位寄存器,写值驱动设备。ARM也会去解析uboot传递的参数,然而并没有那么的复杂,而X86对设备驱动进行了统一的管理,这点与ARM软件架构的实现是有很大区别的,比如,让GPIO的基地址在BIOS中进行统一分配,使用BIOS来统一管理电源等等。。。而ARM就相对来说简单很多,没有这么多的步骤,使用标准的Linux驱动模型+类ARM裸机操作(操作的地址需要进行映射,将物理地址转换成虚拟地址,这点和单片机是不太一样的),也就是说,如果掌握了ARM的驱动模型,同样的,只要我们拥有X86架构的CPU数据手册,我们同样也可以使用ARM的思想来完成对X86架构的CPU的各类驱动BSP的编写。
以下是较为重要的结构体描述:
1在这个结构体里发现,_HID是以内核链表成员的形式加载进Linux内核的
2(内核源码/include/acpi/Acpi_bus.h)
3struct acpi_hardware_id {
4 struct list_head list;
5 char *id;
6};
7
8//ACPI的对象类型结构体
9typedef u32 acpi_object_type;
10//ACPI对象
11union acpi_object {
12 acpi_object_type type; /* See definition of acpi_ns_type for values */
13 struct {
14 acpi_object_type type; /* ACPI_TYPE_INTEGER */
15 u64 value; /* The actual number */
16 } integer;
17
18 struct {
19 acpi_object_type type; /* ACPI_TYPE_STRING */
20 u32 length; /* # of bytes in string, excluding trailing null */
21 char *pointer; /* points to the string value */
22 } string;
23
24 struct {
25 acpi_object_type type; /* ACPI_TYPE_BUFFER */
26 u32 length; /* # of bytes in buffer */
27 u8 *pointer; /* points to the buffer */
28 } buffer;
29
30 struct {
31 acpi_object_type type; /* ACPI_TYPE_PACKAGE */
32 u32 count; /* # of elements in package */
33 union acpi_object *elements; /* Pointer to an array of ACPI_OBJECTs */
34 } package;
35
36 struct {
37 acpi_object_type type; /* ACPI_TYPE_LOCAL_REFERENCE */
38 acpi_object_type actual_type; /* Type associated with the Handle */
39 acpi_handle handle; /* object reference */
40 } reference;
41
42 struct {
43 acpi_object_type type; /* ACPI_TYPE_PROCESSOR */
44 u32 proc_id;
45 acpi_io_address pblk_address;
46 u32 pblk_length;
47 } processor;
48
49 struct {
50 acpi_object_type type; /* ACPI_TYPE_POWER */
51 u32 system_level;
52 u32 resource_order;
53 } power_resource;
54};
55
56typedef char acpi_bus_id[8];
57typedef unsigned long acpi_bus_address;
58typedef char acpi_device_name[40];
59typedef char acpi_device_class[20];
60
61//这是一个位段,用来描述pnp中的类型
62struct acpi_pnp_type {
63 u32 hardware_id:1;
64 u32 bus_address:1;
65 u32 platform_id:1;
66 u32 reserved:29;
67};
68
69//acpi的pnp设备,包括对象名称、ID类型、以及各种ID,具体参考ACPI spec
70struct acpi_device_pnp {
71 acpi_bus_id bus_id; /* Object name */
72 struct acpi_pnp_type type; /* ID type */
73 acpi_bus_address bus_address; /* _ADR */
74 char *unique_id; /* _UID */
75 struct list_head ids; /* _HID and _CIDs */
76 acpi_device_name device_name; /* Driver-determined */
77 acpi_device_class device_class; /* " */
78 union acpi_object *str_obj; /* unicode string for _STR method */
79};
那X86架构的CPU在启动内核的时候又是如何知道BIOS传递过来的HID参数?我们可以来看看X86架构在Linux下的启动流程:
不管是在ARM还是X86平台,本质都是将一系列代码拷贝到对应的存储器对应的区域中,这个存储器一般是NOR FLASH或者NAND FLASH,当然现在还有EMMC等其它的存储设备,然后在执行Uboot(ARM的叫法,也叫bootloader,用来引导内核,而X86用的是BIOS,也差不多)中,通过地址跳转的形式去启动内核,如果是我们自己实现的Bootloader,一般会在作为uboot的第一、第二阶段以后,通过如下的代码跳转到操作系统启动的模式:
1/* 0. 帮内核设置串口: 内核启动的开始部分会从串口打印一些信息,但是内核一开始没有初始化串口 */
2 uart0_init();
3
4 /* 1. 从NAND FLASH里把内核读入内存 */
5 puts("Copy kernel from nand\n\r");
6 nand_read(0x60000+64, (unsigned char *)0x30008000, 0x200000);
7 puthex(0x1234ABCD);
8 puts("\n\r");
9 puthex(*p);
10 puts("\n\r");
11
12 /* 2. 设置参数 */
13 puts("Set boot params\n\r");
14 setup_start_tag();
15 setup_memory_tags();
16 setup_commandline_tag("noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0");
17 setup_end_tag();
18
19 /* 3. 跳转执行 */
20 puts("Boot kernel\n\r");
21 theKernel = (void (*)(int, int, unsigned int))0x30008000;
22 theKernel(0, 362, 0x30000100);
如上代码段,Linux内核在启动的过程中会去解析ARM传递过去的参数:noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0。
ARM的启动相对来说比较简单: uboot----->内核------>文件系统------>app,在uboot之前一般还会有IC厂商的固件驱动代码。
而X86架构的CPU与ARM的启动形式就不太一样,显然比这里要复杂得多,由于BIOS的源代码并不开放,所以我们也并不知道BIOS的内幕具体是怎么实现的,但我们可以从以下这张图可以得知X86架构从BIOS到kernel的整个流程,在这里我们能够得知,X86的OS和BIOS之间衔接的桥梁是ACPI,使用ACPI来对一些资源进行统一管理,我们要获取的这个Hardware ID其实就是ACPI Tables中的其中一个参数。
到这里我们就明白了,不懂BIOS是怎么实现的也没有什么关系,我们只要去百度下载一个ACPI的Spec,不就可以知道BIOS中具体的工作是做什么了吗?只要了解了BIOS和内核之间是要完成什么样的事情,对于我们驱动工程师来说就已经足够了。
接下来我们来看看在X86 Linux内核的启动过程中,是如何去识别BIOS传递过来的Hardware ID的?
不管是ARM架构的还是X86架构的CPU,在启动Linux内核的时候一定要进入start_kernel函数,这个函数位于:
内核源码/init/main.c
在这个函数中,会做操作系统的设备等一系列初始化,与ACPI最关键的地方在这个函数:acpi_early_init,这里完成的工作主要有如下:
1acpi_early_init
2acpi_reallocate_root_table
3acpi_initialize_subsystem
4(drivers/acpi/acpica/Tbxfload.c)
51.acpi_load_tables:
6--->acpi_status __init acpi_load_tables(void)
72.acpi_tb_load_namespace:
8--->static acpi_status acpi_tb_load_namespace(void)
93.acpi_ns_load_table
10在table中会得到一系列参数,包括Hardware ID,需要根据不同的参数表来解析
11--->
12(1)acpi_ut_acquire_mutex
13(2)acpi_tb_is_table_loaded
14(3)acpi_tb_allocate_owner_id
15(4)acpi_ns_parse_table
原来,内核就是这样来获取BIOS传递过来的table的,这个table中就会包括Hardware ID,当然还会有其它的ID,具体请参考ACPI的Spec,根据Linux实现的驱动模型,那么有设备,自然就要有驱动,驱动和设备要相辅相成,在:内核源码/drivers/acpi/bus.c中就实现了acpi的驱动,在这个文件中,我们看到:
1static int __init acpi_init(void)
2{
3 int result;
4
5 if (acpi_disabled) {
6 printk(KERN_INFO PREFIX "Interpreter disabled.\n");
7 return -ENODEV;
8 }
9
10 acpi_kobj = kobject_create_and_add("acpi", firmware_kobj);
11 if (!acpi_kobj) {
12 printk(KERN_WARNING "%s: kset create error\n", __func__);
13 acpi_kobj = NULL;
14 }
15
16 init_acpi_device_notify();
17 result = acpi_bus_init();
18 if (result) {
19 disable_acpi();
20 return result;
21 }
22
23 pci_mmcfg_late_init();
24 acpi_scan_init();
25 acpi_ec_init();
26 acpi_debugfs_init();
27 acpi_sleep_proc_init();
28 acpi_wakeup_device_init();
29 return 0;
30}
那么acpi_init函数又是怎么被内核调用的呢?通过subsys_initcall(acpi_init)这个宏来调用,我们将subsys_initcall展开看看,在内核源码/include/init.h
1#define subsys_initcall(fn) __define_initcall(fn, 4)
将__define_initcall(fn,4)这个宏继续展开:
1#define __define_initcall(fn, id) \
2 static initcall_t __initcall_##fn##id __used \
3 __attribute__((__section__(".initcall" #id ".init"))) = fn; \
4 LTO_REFERENCE_INITCALL(__initcall_##fn##id)
其中initcall_t是函数指针,原型:typedef int (*initcall_t)(void);
属性 __attribute__((__section__())) 则表示把对象放在一个这个由括号中的名称所指代的section中,这个对象就是我们的acpi_init函数。由此可见__define_initcall主要是完成以下几个功能:
(1)声明一个名称为__initcall_##fn的函数指针;
(2) 将这个函数指针初始化为fn;
(3) 编译的时候需要把这个函数指针变量放置到名称为 ".initcall" level ".init"的section中。
而对应的这些.include,level,.init定义在Vmlinux.lds.h中,这个文件在内核源码/include/asm-generic/Vmlinux.lds.h中:
在Linux4.0的内核实现如下:
1#define INIT_CALLS_LEVEL(level) \
2 VMLINUX_SYMBOL(__initcall##level##_start) = .; \
3 *(.initcall##level##.init) \
4 *(.initcall##level##s.init) \
5#define INIT_CALLS \
6 VMLINUX_SYMBOL(__initcall_start) = .; \
7 *(.initcallearly.init) \
8 INIT_CALLS_LEVEL(0) \
9 INIT_CALLS_LEVEL(1) \
10 INIT_CALLS_LEVEL(2) \
11 INIT_CALLS_LEVEL(3) \
12 INIT_CALLS_LEVEL(4) \
13 INIT_CALLS_LEVEL(5) \
14 INIT_CALLS_LEVEL(rootfs) \
15 INIT_CALLS_LEVEL(6) \
16 INIT_CALLS_LEVEL(7) \
17 VMLINUX_SYMBOL(__initcall_end) = .;
__initcall_start和__initcall_end以及INITCALLS中定义的SECTION都是在arch/x86/kernel/vmlinux.lds.S中放在.init.begin段中的,如下代码,这是linux4.0内核中实现的:
1SECTIONS{
2 ......
3/* Init code and data - will be freed after init */
4 . = ALIGN(PAGE_SIZE);
5 .init.begin : AT(ADDR(.init.begin) - LOAD_OFFSET) {
6 __init_begin = .; /* paired with __init_end */
7 }
8 ......
9 . = ALIGN(PAGE_SIZE);
10
11 /* freed after init ends here */
12 .init.end : AT(ADDR(.init.end) - LOAD_OFFSET) {
13 __init_end = .;
14 }
15 ......
16}
而这些SECTION里的函数在初始化时被顺序执行,具体的调用流程是这样的:
rest_init ====> kernel_thread(kernel_init, NULL, CLONE_FS) ====> kernel_init ====> kernel_init_freeable ====>do_basic_setup ====> do_initcalls
在内核启动的最后一步,开启一条内核线程来加载这些函数,从而成功装载acpi驱动。
1static void __init do_initcalls(void)
2{
3 int level;
4
5 for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
6 do_initcall_level(level);
7}
接下来再接着看acpi_init函数,这个函数中会调用acpi_scan_init函数,acpi_scan_init函数会完成如下:
1、注册ACPI总线
1result = bus_register(&acpi_bus_type);
2、完成与apci相关的一系列初始化
1acpi_pci_root_init();
2acpi_pci_link_init();
3acpi_processor_init();
4acpi_lpss_init();
5acpi_apd_init();
6acpi_cmos_rtc_init();
7acpi_container_init();
8acpi_memory_hotplug_init();
9acpi_pnp_init();
10acpi_int340x_thermal_init();
3、重点:调用acpi_bus_scan函数
在这个函数中会继续调用acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,acpi_bus_check_add, NULL, NULL, &device);
注册acpi_bus_check_add函数,在acpi_bus_check_add函数中继续调用:acpi_add_single_object函数:
static int acpi_add_single_object(struct acpi_device **child,acpi_handle handle, int type,unsigned long long sta)
在acpi_add_single_object函数中的主要操作:
1、调用acpi_init_device_object等完成acpi设备、电源管理相关等的初始化,详情见后面分析
2、调用acpi_device_add获取设备的HID信息,实际上是通过链表的遍历形式去获取
1 list_for_each_entry(acpi_device_bus_id, &acpi_bus_id_list, node) {
2 if (!strcmp(acpi_device_bus_id->bus_id,
3 acpi_device_hid(device))) {
4 acpi_device_bus_id->instance_no++;
5 found = 1;
6 kfree(new_bus_id);
7 break;
8 }
9 }
10 const char *acpi_device_hid(struct acpi_device *device)
11 {
12 struct acpi_hardware_id *hid;
13 //判断链表是否为空,如果为空,返回无效的hid,其实是一个字串:"device"
14 if (list_empty(&device->pnp.ids))
15 return dummy_hid;
16 //通过list成员返回该结构体的起始地址,也就是acpi_hardware_id这个结构体的起始地址
17 hid = list_first_entry(&device->pnp.ids, struct acpi_hardware_id, list);
18 //找到该结构体的起始地址后,即可以获得结构体中的id成员,这个id就是我们当前要获取的HID
19 return hid->id;
20 }
3、通过dev_set_name函数
1 dev_set_name(&device->dev, "%s:%02x", acpi_device_bus_id->bus_id, acpi_device_bus_id->instance_no);
设置在文件系统中/sys/devices/XXX下面的name
4、调用acpi_init_device_object函数:
1void acpi_init_device_object(struct acpi_device *device, acpi_handle handle,int type, unsigned long long sta)
(1)、初始化内核链表用来存储pnp设备中关于的链表等其它的信息
1INIT_LIST_HEAD(&device->pnp.ids);
2device->device_type = type;
3device->handle = handle;
4....
(2)、调用acpi_set_pnp_ids将ids的保存到ids中,具体操作见后面的剖析
5、调用acpi_set_pnp_ids函数:
1static void acpi_set_pnp_ids(acpi_handle handle, struct acpi_device_pnp *pnp,int device_type)
2
首先会根据swicth语句来判断设备类型:device_type,这里找到的是ACPI总线的设备类型ACPI_BUS_TYPE_DEVICE
1switch (device_type)
2{
3...
4case ACPI_BUS_TYPE_DEVICE:
5...
6}
7case ACPI_BUS_TYPE_DEVICE:
在该选项ACPI_BUS_TYPE_DEVICE中:
5.1 首先会判断acpi句柄是否为ACPI的根对象,如果是,则会直接添加id节点到pnp->ids的链表中去。
5.2 接下来,调用acpi_get_object_info函数:
1acpi_status acpi_get_object_info(acpi_handle handle,struct acpi_device_info **return_buffer)
2
通过acpi_get_object_info这个函数得到设备的_HID和_CIDs信息,获取之前需要对命名空间的句柄进行转换,怎么转?
通过acpi_ns_validate_handle这个函数转。
1struct acpi_namespace_node *acpi_ns_validate_handle(acpi_handle handle)
acpi_ns_validate_handle 对传入的名字空间句柄转换为名字空间节点,这是在处理根节点的特殊情况。
这个句柄其实是:
1typedef void *acpi_handle; /* Actually a ptr to a NS Node */
为什么是Object?在ACPI标准手册上关于ASL语言中可以查询到这样的描述:
ObjectType must have. A fixed list is written as ( a , b , c , … ) where the number of arguments depends on the specific ObjectType , and some elements can be nested objects, that is (a, b, (q, r, s,t), d) .
大致意思是,对象类型一定要包含,它是一个固定的列表写成(a,b,c...)参数,取决于特定的对象类型,有些元素也是可以嵌套的,比如(a,b,(q,r,s,t),d)。
该函数中会尝试去判断函数传过来的参数--句柄是否存在,或者句柄是否为根对象:
if ((!handle) || (handle == ACPI_ROOT_OBJECT)),只要有一个成立,则会return (acpi_gbl_root_node);
接下来尝试校验句柄:
if (ACPI_GET_DESCRIPTOR_TYPE(handle) != ACPI_DESC_TYPE_NAMED)
如果该句柄不是描述命名空间类型的句柄,则会return (NULL);
以上条件都不满足,则:return (ACPI_CAST_PTR(struct acpi_namespace_node, handle));
#define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
它的原型是将命名空间句柄强制转换为apci命名空间节点,因为只有这样,才能正确的解析BIOS传递过来的关于_HID的信息。
(1)提供运行_HID/_UID/_SUB/_CID的方法,这里只看_HID的执行方法
1if ((type == ACPI_TYPE_DEVICE) || (type == ACPI_TYPE_PROCESSOR)) {
2 ...
3 //得到_HID的信息
4 status = acpi_ut_execute_HID(node, &hid);
5 if (ACPI_SUCCESS(status)) {
6 info_size += hid->length;
7 valid |= ACPI_VALID_HID;
8 }
9 ...
10 }
(2)复制ID信息到返回缓冲区 or 保留区域 & 检测id是否为PCI根桥
acpi_ns_copy_device_id //将HID、UID、SUB和CIDs复制到返回缓冲区,如果是可变长度的字符串则会被复制到保留区域
acpi_ut_is_pci_root_bridge //对于HID和CID,会检查ID是否为PCI根桥,如果是,则要info->flags |= ACPI_PCI_ROOT_BRIDGE;
3、保存HID等ID的信息到device的pnp->ids里,这里只分析HID,同样是利用了内核链表的尾插机制,将id源源不断的接在链表的尾部
1if (info->valid & ACPI_VALID_HID) {
2 acpi_add_id(pnp, info->hardware_id.string);
3 pnp->type.platform_id = 1;
4}
5static void acpi_add_id(struct acpi_device_pnp *pnp, const char *dev_id)
6 最关键的一步:
7 list_add_tail(&id->list, &pnp->ids);
8 如果没有拥有相关的HID,可以直接对Handle进行添加,而不用通过BIOS去获取:
9 if (acpi_is_video_device(handle))
10 acpi_add_id(pnp, ACPI_VIDEO_HID);
11 else if (acpi_bay_match(handle))
12 acpi_add_id(pnp, ACPI_BAY_HID);
13 else if (acpi_dock_match(handle))
14 acpi_add_id(pnp, ACPI_DOCK_HID);
15 else if (acpi_ibm_smbus_match(handle))
16 acpi_add_id(pnp, ACPI_SMBUS_IBM_HID);
17 else if (list_empty(&pnp->ids) &&
18 acpi_object_is_system_bus(handle)) {
19 /* \_SB, \_TZ, LNXSYBUS */
20 acpi_add_id(pnp, ACPI_BUS_HID);
21 strcpy(pnp->device_name, ACPI_BUS_DEVICE_NAME);
22 strcpy(pnp->device_class, ACPI_BUS_CLASS);
23 }
例如:#define ACPI_BAY_HID "LNXIOBAY",那么PNP设备又是如何被加载到ACPI中的呢?而Hardware ID传进来的字符串又是如何被PNP识别的呢?接下来请看内核源码/drivers/acpi/acpi_pnp.c
1void __init acpi_pnp_init(void)
2{
3 acpi_scan_add_handler(&acpi_pnp_handler);
4}
acpi_pnp_init这个函数是在acpi_scan_init中被调用的,也就是前面讲到的。接下来我们来看看acpi_scan_add_handler这个函数:
1int acpi_scan_add_handler(struct acpi_scan_handler *handler)
2{
3 if (!handler)
4 return -EINVAL;
5
6 list_add_tail(&handler->list_node, &acpi_scan_handlers_list);
7 return 0;
8}
很明显,这个函数完成的功能就是将节点插入到链表中去,插入的是什么节点?我们来看看acpi_pnp_handler:
1static struct acpi_scan_handler acpi_pnp_handler = {
2 .ids = acpi_pnp_device_ids,
3 .match = acpi_pnp_match,
4 .attach = acpi_pnp_attach,
5};
这是一个结构体变量,这里的ids其实就是一个字符串,这个字符串就是acpi的设备id,只不过在这被初始化成了pnp设备id,其实是一个意思,因为PNP设备是注册在ACPI之上的。
1struct acpi_device_id {
2 __u8 id[ACPI_ID_LEN];
3 kernel_ulong_t driver_data;
4};
1static const struct acpi_device_id acpi_pnp_device_ids[] = {
2 /* pata_isapnp */
3 {"PNP0600"}, /* Generic ESDI/IDE/ATA compatible hard disk controller */
4 /* floppy */
5 {"PNP0700"},
6 /* ipmi_si */
7 {"IPI0001"},
8 ......
9};
而acpi_pnp_match是完成对BIOS传递过来的ID与这里的ID进行比较,如果存在这个ID,才会将对应的驱动注册到内核中去,这样内核才会去执行对应的驱动:
1static bool matching_id(char *idstr, char *list_id)
2{
3 int i;
4 if (memcmp(idstr, list_id, 3)){
5 return false;
6 }
7
8 for (i = 3; i < 7; i++) {
9 char c = toupper(idstr[i]);
10
11 if (!isxdigit(c)
12 || (list_id[i] != 'X' && c != toupper(list_id[i])))
13 return false;
14 }
15 return true;
16}
17
18static bool acpi_pnp_match(char *idstr, const struct acpi_device_id **matchid)
19{
20 const struct acpi_device_id *devid;
21
22 for (devid = acpi_pnp_device_ids; devid->id[0]; devid++) {
23 if (matching_id(idstr, (char *)devid->id)) {
24 if (matchid)
25 *matchid = devid;
26
27 return true;
28 }
29 }
30
31 return false;
32}
33
34static int acpi_pnp_attach(struct acpi_device *adev,
35 const struct acpi_device_id *id)
36{
37 return 1;
38}
至此,我们已经完全明白内核是如何接收到BIOS传过来的Hardware ID的整个流程,确实是非常难的,简单的问题被复杂化,但没有办法,因为要统一管理的东西太多太多了,所以一定需要一个模型来进行管理。如果我们不想使用BIOS与ACPI的机制,完全也可以绕开这个流程,用标准的Linux驱动模型去实现,不过还是建议,还是使用标准的ACPI的流程,这样才有助于软件工程项目管理。
参考文章:
http://blog.csdn.net/jiangwei0512
http://blog.csdn.net/morixinguan/article/details/79138325
http://blog.chinaunix.net/uid-27717694-id-3624294.html
http://blog.csdn.net/wh_19910525/article/details/16370863
https://www.ibm.com/developerworks/cn/linux/l-acpi/part1/
http://www.latelee.org/embedded-linux/kernel-note-7%EF%BC%8Dintel-lpc_ich-driver.html
http://www.latelee.org/embedded-linux/kernel-note-10-intel-gpio-driver.html