linux驱动基础系列--Linux下Spi接口Wifi驱动分析

2022-11-20 15:44:20

前言

　　本文纯粹的纸上谈兵，我并未在实际开发过程中遇到需要编写或调试这类驱动的时候，本文仅仅是根据源码分析后的记录！基于内核版本：2.6.35.6 。主要是想对spi接口的wifi驱动框架有一个整体的把控，因此会忽略一些硬件上操作的系统，同时里面涉及到的一些驱动基础，比如数据结构、设备模式也不进行详细说明原理。如果有任何错误地方，请指出，谢谢！

分两步来分析：

第一步：spi接口驱动分析

第二部：基于spi接口的wifi驱动分析

spi接口驱动分析

在cm-x270.c中

static void __init cmx270_init_spi(void)

{

	pxa2xx_set_spi_info(2, &cm_x270_spi_info);

	spi_register_board_info(ARRAY_AND_SIZE(cm_x270_spi_devices));

}

void __init cmx270_init(void)

{

	pxa2xx_mfp_config(ARRAY_AND_SIZE(cmx270_pin_config));

#ifdef CONFIG_PM

	pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);

#endif

	cmx270_init_rtc();

	cmx270_init_mmc();

	cmx270_init_ohci();

	cmx270_init_2700G();

	cmx270_init_spi();

}

pxa2xx_set_spi_info实际上是向平台总线注册spi控制器设备。在drivers/spi/pxa2xx_spi.c中有对应的spi控制器的驱动注册：

static int __init pxa2xx_spi_init(void)

{

	return platform_driver_probe(&driver, pxa2xx_spi_probe);

}

这样匹配成功后导致pxa2xx_spi_probe的执行，在pxa2xx_spi_probe中，主要是根据cm_x270_spi_info实例化一个spi控制器对象，然后初始化控制器，申请资源，最后调用spi_register_master将该spi控制器实例注册到设备模型上去。里面核心的操作就是scan_boardinfo(master)它会扫描注册的spi设备。这个就是之前函数

spi_register_board_info(ARRAY_AND_SIZE(cm_x270_spi_devices));

调用的结果，它会将cm_x270_spi_devices信息添加到一个全局的链表（中间会wrap一层）。

scan_boardinfo会将全局链表里面总线号和自己匹配的设备都进行注册，即调用spi_new_device，将设备注册到spi总线上去。于是，spi控制器和spi设备（wifi） 都已经准备完毕，剩下的就等spi接口的wifi驱动注册了。

基于spi接口的wifi驱动分析

因为分析的spi接口的wifi驱动是Marvell公司的，所以spi接口的wifi驱动部分看：

linux/drivers/net/wireless/libertas/if_spi.c ，它在

static int __init if_spi_init_module(void)

{

	int ret = 0;

	lbs_deb_enter(LBS_DEB_SPI);

	printk(KERN_INFO "libertas_spi: Libertas SPI driver\n");

	ret = spi_register_driver(&libertas_spi_driver);

	lbs_deb_leave(LBS_DEB_SPI);

	return ret;

}

中调用了spi_register_driver向spi总线注册驱动，这会导致if_spi_probe的调用，它内部会创建一个对象来描述该spi接口的wifi，即struct if_spi_card *card;。同时，也会装载固件到wifi设备中，它是通过if_spi_prog_helper_firmware和if_spi_prog_main_firmware实现的。

　　关于固件的主要作用

　　 Firmware是在Wi-Fi设备硬件中执行的一段程序，系统上电后由WLAN驱动将其下载到Wi-Fi模块中，实现Wi-Fi硬件接口控制、数据缓冲、802.11与802.3帧类型转换、802.1l MAC层管理、WLAN MAC中断管理以及硬件控制等功能。发送数据时，Host驱动程序将从上层接收到的标准802.3帧发送给Firmware，Firmware将收到的数据帧转换成802.11帧，再通过无线连接将数据传输出去；接收数据时，Firmware将接收到的所有802.11帧转换成802.3帧后，通过SPI口发送给Host驱动。由此可见，Wi-Fi无线网卡设备在Linux中是被当作普通的以太网设备对待的，在Wi-Fi驱动程序中无需实现802.11帧与802.3帧之间的类型转换。

然后会将刚申请并初始化完成的card注册到libertas中，即调用：lbs_add_card(card, &spi->dev); lbs_add_card的主要作用是让card成为net device功能，它调用alloc_netdev申请了一个网络设备，需要注意的是赋予了网络子系统将来会用到的操作集lbs_netdev_ops

static const struct net_device_ops lbs_netdev_ops = {

	.ndo_open 		= lbs_dev_open,

	.ndo_stop		= lbs_eth_stop,

	.ndo_start_xmit		= lbs_hard_start_xmit,

	.ndo_set_mac_address	= lbs_set_mac_address,

	.ndo_tx_timeout 	= lbs_tx_timeout,

	.ndo_set_multicast_list = lbs_set_multicast_list,

	.ndo_change_mtu		= eth_change_mtu,

	.ndo_validate_addr	= eth_validate_addr,

};

同时注意下面的调用，后面会基于这些通信：

        init_waitqueue_head(&priv->waitq);

        priv->main_thread = kthread_run(lbs_thread, dev, "lbs_main");

	if (IS_ERR(priv->main_thread)) {

		lbs_deb_thread("Error creating main thread.\n");

		goto err_ndev;

	}

	priv->work_thread = create_singlethread_workqueue("lbs_worker");

	INIT_DELAYED_WORK(&priv->assoc_work, lbs_association_worker);

	INIT_DELAYED_WORK(&priv->scan_work, lbs_scan_worker);

	INIT_WORK(&priv->mcast_work, lbs_set_mcast_worker);

接着if_spi_probe里面会调用：

 priv->hw_host_to_card = if_spi_host_to_card;

它会在Libertas层收到网络子系统数据的时候调用

 card->spi_thread = kthread_run(lbs_spi_thread, card, "lbs_spi_thread");

负责数据包的接收和命令的响应处理线程

 err = request_irq(spi->irq, if_spi_host_interrupt,

                            IRQF_TRIGGER_FALLING, "libertas_spi", card);

用于处理spi接口网卡上的中断

 err = lbs_start_card(priv);

它的调用链是

lbs_cfg_register -> wiphy_register ->register_netdev

，这样之后网络子系统就能够使用该网卡驱动了。

下面分几个情景分析上面这些核心函数的作用

情景分析

情景1：上层网络子系统有数据发送

lbs_hard_start_xmit函数会被调用，这个函数属于上文说过的网络子系统将来会用到的操作集lbs_netdev_ops，lbs_hard_start_xmit首先将数据包拷贝到自己的buf里面，然后唤醒其他线程然后退出，priv是libertas层维护的对象，是在上文中lbs_add_card的时候分配的。

调用层次

lbs_add_card -> lbs_cfg_alloc -> wdev->wiphy = wiphy_new(&lbs_cfg80211_ops, sizeof(struct lbs_private)); ， 属于wdev额外分配的一段内存，可以通过priv = wdev_priv(wdev);获取。 wake_up(&priv->waitq);实际唤醒的是lbs_thread线程，由于是发送数据包，会调用lbs_execute_next_command，接着会导致lbs_submit_command -> priv->hw_host_to_card

priv->hw_host_to_card是上文中说过的if_spi_host_to_card，因为是通过spi接口发送数据，所以调用spi驱动probe时注册的函数是理所当然的。

if_spi_host_to_card最终会导致spi控制器实例的master->transfer会被调用，它是在第一步中的pxa2xx_spi_probe里注册master->transfer = transfer;，transfer实际上就是最终的硬件操作了，但它实际上也是异步的，它呼叫一个工作线程去完成这些任务

if (drv_data->run == QUEUE_RUNNING && !drv_data->busy)

		queue_work(drv_data->workqueue, &drv_data->pump_messages);

drv_data->workqueue也是在pxa2xx_spi_probe完成的：

init_queue

		-> tasklet_init(&drv_data->pump_transfers,

			pump_transfers,	(unsigned long)drv_data);

		-> INIT_WORK(&drv_data->pump_messages, pump_messages);

		-> drv_data->workqueue = create_singlethread_workqueue(

				dev_name(drv_data->master->dev.parent));

最终pump_messages会被调用. 它最后会导致pump_transfers来完成硬件数据传送。

这个过程确实非常绕，下面分析下为什么需要这些过程:

首先是lbs_thread，它的存在不仅仅是处理数据的发送，同时还要处理设备返回的事件和命令的响应。上层数据包发送的时候，我们应该尽可能快的完成处理并返回，不然网络子系统就会延迟了，但这并不是最主要的， 将一类事件异步统一到一个线程里面处理也是有很多优势的。然后是priv->hw_host_to_card的回调问题，网卡驱动的libertas层实际上是和具体的硬件接口分离的，不然它还得关心是spi接口、sdio接口、或者是usb接口的wifi等等，所以采用回调的方式，让具体的接口处理部分注册回调函数。

if_spi_host_to_card调用spi控制器实例的master->transfer很容易理解，具体的数据传送当然的操作控制器。

对于控制器里面的实现，即master->transfe的transfer 它采用工作线程的方式来统一处理所有的发送数据包，这样就可以和lbs_thread实现异步，各种更容易处理各自的队列等。

情景二：设备接收到数据

Spi接口的wifi有数据过来的时候，会通过spi中断，所以理所当然的进入注册的spi irq的中断处理函数if_spi_host_interrupt，它的实现很简单，异步处理，自己本身不进行任何处理（毕竟在中断，处理spi有可能sleep，那就玩玩了，呵呵），即调用up(&card->spi_ready)唤醒其他线程来做事情。

睡在这信号量上的线程是：lbs_spi_thread，这个是上文第一步中的if_spi_probe中创建的，这个好理解啦。它的处理函数lbs_spi_thread，读状态寄存器，根据状态来决定是什么事件。

/* Read the host interrupt status register to see what we

 * can do. */

err = spu_read_u16(card, IF_SPI_HOST_INT_STATUS_REG,

                   &hiStatus);

数据的处理就在：

 if (hiStatus & IF_SPI_HIST_RX_UPLOAD_RDY)

             err = if_spi_c2h_data(card);

             if (err)

                        goto err;

if_spi_c2h_data的处理和其他网卡的处理类似，分配sk_buff 然后读到分配的buff里面（读可以直接读，也可以用dma），然后调用lbs_process_rxed_packet经过一些处理调用netif_rx来传给网络子系统。

情景三：命令的响应处理

和情景二类似，都是在lbs_spi_thread中，不过是进入了另一个判断里面：

if (hiStatus & IF_SPI_HIST_CMD_UPLOAD_RDY)

              err = if_spi_c2h_cmd(card);

              if (err)

                         goto err;

if_spi_c2h_cmd命令的响应当然没必要让网络子系统知道，因为对于网络子系统，spi wifi就是一个网络设备而已，不知道这些具体的命令的含义。我们这个理所当然的是让libertas层的lbs_thread线程处理，这个上文 情景1：上层网络子系统有数据发送 已经有过分析。它会进入到

if (priv->resp_len[resp_idx]) {

             spin_unlock_irq(&priv->driver_lock);

             lbs_process_command_response(priv,

                         priv->resp_buf[resp_idx],

                         priv->resp_len[resp_idx]);

             spin_lock_irq(&priv->driver_lock);

             priv->resp_len[resp_idx] = 0;

}

最终调用lbs_process_command_response来处理命令的响应。

完！

2014年5月

上一篇：Linux驱动中的platform总线分析


下一篇：手把手教你从零实现Linux misc设备驱动一(基于友善之臂4412开发板)