写在前面的话：

本文是博主学习linux驱动移植整整两周后通过查阅资料并结合自己的一些观察所做的一些记录，旨在作为日后温习材料，由于博主尚无太多经验文中内可能会出现一些谬误，希望看到的热心朋友能拍砖指正。

在我前面的日中已经提到了我所做的SC16C550的串口移植，本来是没有什么技术难度，但对于新人来讲了解内核代码的结构和移植的原理是首要的，于是在工作中就做了一些记录。

//////////////////////////////////////////////////gap//////////////////////////////////////////////////////

在Linux-2.6 16c550 串口驱动移植一文中的static struct platform_device sc16550_device结构体在配置好以后，使用了linux内核模型的platform总线机制中设备注册接口函数：platform_device_register(&sc16550_device);将 sc16550_device 设备挂载到了platform bus上。上文已经提到驱动所使用的正是 8250来进行驱动，所以在8250.c驱动init时，调用的platform_driver_register(&serial8250_isa_driver);函数正是加载该驱动到platform bus上，

下面是关于sc16550_device的重要的结构体的配置具体情况：

static struct plat_serial8250_port sc16550_data[] = {
.mapbase  = sc16550_UART_BASE, //flags使用IOREMAP，8250驱动会自动映射mapbase
.irq = sc16550_UART_IRQ,
.uartclk  = sc16550_UART_BAUD * 16,
.iotype  = UPIO_MEM,
.flags  = UPF_BOOT_AUTOCONF | 
                          UPF_SKIP_TEST | UPF_IOREMAP,
        .regshift       = 0,
};
static struct platform_device sc16550_device = {
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = { .platform_data = sc16550_data, },
};

而serial8250_isa_driver结构体的定义为：

static struct platform_driver serial8250_isa_driver = {
.probe = serial8250_probe,
.remove = __devexit_p(serial8250_remove),
.suspend = serial8250_suspend,
.resume = serial8250_resume,
.driver = {
.name = "serial8250",
.owner = THIS_MODULE,
},
};

那么在sc16550_device设备和serial8250_isa_driver驱动具体是怎样加载到总线中，而两者之间又是如何匹配相认的呢？从而团结一心一致对外的呢？

今天我们就一起深究一下吧……

当设备挂接到总线上时，与总线上的所有驱动进行匹配(用bus_type.match进行匹配)，如果匹配成功,则调用bus_type.probe或者driver.probe初始化该设备，挂接到总线上如果匹配失败，则只是将该设备挂接到总线上。

驱动挂接到总线上时，与总线上的所有设备进行匹配(用bus_type.match进行匹配)， 如果匹配成功,则调用bus_type.probe或者driver.probe初始化该设备；挂接到总线上如果匹配失败，则只是将该驱动挂接到总线上。

那么现在我们无法判断到底我们的sc16550_device和serial8250_isa_driver是哪一个先挂载到总线上的。不过这也并不影响我们理解剖析整个linux设备模型。

因为实际上platform_bus_type总线先被kenrel注册，有必要对platform_bus_type 的定义作一番注释，其 定义如下： 
struct bus_type platform_bus_type = { 
       .name         = "platform",       // bus 的名字，将会生成/sys/bus/platform  目录