linux驱动编写（platform总线和网卡驱动）

【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】

    对于linux驱动来说，一般的架构还是按照bus－host－device的形式来进行的。比如就拿usb来说，通常如果是新的soc，只需要适配一下host就可以了。但是如果要适配其他的usb外接设备，那么需要自己编写device driver。同样，目前pc用到最多的还是pcie，所以你会发现pc上编写的driver大多数都是适配不同功能类型的device driver。然而，对于soc来说，它应该怎么处理？其实，linux已经为我们想出了办法，那就是platform bus。platform是一个虚拟总线，要使用它，只需要两步就可以。这里，不妨以mini2440常用的dm9000网卡举例说明。

1、注册dm9000设备

    对于bus设备，一般如果device上线了，那么driver会自动加载。但是platform bus是一个假的总线，所以不可能自动加载。这个时候，系统就需要我们手动添加设备，这样后续也可以实现自动加载driver了。因此在arch/arm/mach-s3c24xx/mach-mini2440.c就存在这么一段代码，

static struct platform_device mini2440_device_eth = {
	.name		= "dm9000",
	.id		= -1,
	.num_resources	= ARRAY_SIZE(mini2440_dm9k_resource),
	.resource	= mini2440_dm9k_resource,
	.dev		= {
		.platform_data	= &mini2440_dm9k_pdata,
	},
};

2、编写dm9000驱动，这段代码位于drivers/net/ethernet/davicom/dm9000.c

    只要dm9000被注册，那么这里的驱动就会被加载。

static struct platform_driver dm9000_driver = {
	.driver	= {
		.name    = "dm9000",
		.pm	 = &dm9000_drv_pm_ops,
		.of_match_table = of_match_ptr(dm9000_of_matches),
	},
	.probe   = dm9000_probe,
	.remove  = dm9000_drv_remove,
};

    由于之前dm9000设备已经注册，那么在insmod dm9000.ko的时候，代码会一直执行下去。因为linux会在注册dm9000驱动之时，发现当前正好有一个dm9000的设备，所以会直接调用probe函数。当然在probe函数里面，它还会注册dm9000_netdev_ops结构、通过request_irq注册中断，基本的驱动结构基本上就是这样的。

3、mini2440的其他设备驱动

    有了dm9000的范例，你会发现soc上的大部分驱动默不是用这种方法完成的，这大概也是soc特有的一种的驱动方式吧。

    比如gpio驱动，

static struct platform_device mini2440_button_device = {
	.name		= "gpio-keys",
	.id		= -1,
	.dev		= {
		.platform_data	= &mini2440_button_data,
	}
};

    比如led驱动，

static struct platform_device mini2440_led1 = {
	.name		= "s3c24xx_led",
	.id		= 1,
	.dev		= {
		.platform_data	= &mini2440_led1_pdata,
	},
};

static struct platform_device mini2440_led2 = {
	.name		= "s3c24xx_led",
	.id		= 2,
	.dev		= {
		.platform_data	= &mini2440_led2_pdata,
	},
};

static struct platform_device mini2440_led3 = {
	.name		= "s3c24xx_led",
	.id		= 3,
	.dev		= {
		.platform_data	= &mini2440_led3_pdata,
	},
};

static struct platform_device mini2440_led4 = {
	.name		= "s3c24xx_led",
	.id		= 4,
	.dev		= {
		.platform_data	= &mini2440_led4_pdata,
	},
};

static struct platform_device mini2440_led_backlight = {
	.name		= "s3c24xx_led",
	.id		= 5,
	.dev		= {
		.platform_data	= &mini2440_led_backlight_pdata,
	},
};

    比如声卡驱动，

static struct platform_device mini2440_audio = {
	.name		= "s3c24xx_uda134x",
	.id		= 0,
	.dev		= {
		.platform_data	= &mini2440_audio_pins,
	},
};

    如果需要看所有的platform设备注册情况，只需要看这个结构体就可以了。

static struct platform_device *mini2440_devices[] __initdata = {
	&s3c_device_ohci,
	&s3c_device_wdt,
	&s3c_device_i2c0,
	&s3c_device_rtc,
	&s3c_device_usbgadget,
	&mini2440_device_eth,
	&mini2440_led1,
	&mini2440_led2,
	&mini2440_led3,
	&mini2440_led4,
	&mini2440_button_device,
	&s3c_device_nand,
	&s3c_device_sdi,
	&s3c2440_device_dma,
	&s3c_device_iis,
	&uda1340_codec,
	&mini2440_audio,
};

    soc的驱动流程远没有大家想象的那么复杂，建议大家循着这个脉络慢慢学，总能找到适合自己的学习方法。   

 ps:

    有同学可能好奇，这么多驱动都在，怎么没有dram和pll呢？其实这两个呢，一般在uboot里面就配置好了，不再修改了。