WiFi driver architecture for Solaris ------------------------------------ Abbreviations: GLD: Generic Lan Driver LLD: Low Level Driver 1. Overview The wifi drivers in solaris are multi-threaded, loadable, GLDv3-based STREAM drivers. Functionally speaking, besides the common part as GLD-based driver, the wifi driver also includes two special parts, one is for the 802.11 protocol, and the other is for hardware related operations. As to ieee80211 protocol, solaris has a kernel module -- net80211, implementing the management functionalities according to the specs. The 802,11 protocol part in the driver includes callback functions registered to the net80211 module and the calling to the functions exported by the net80211 module. As to the hardware part, the driver includes a hardware depedent LLD(Low Level Driver) part to implement hardware related operations. 2. Architecture and data flow chart 2.1 Architecture The following is the overall structure of relationship between the wifi driver and the remaining part of solaris, in which part [1] [2] [3] belong to the wifi driver. $$$$$$$$$$$$$ $ user land $ $$$$$$$$$$$$$ ================= ====================== | | | config tool: | | ftp, telent, | | ifconfig(1M), | | etc | | wificonfig(1M), | | | | dladm(1M) | ================= ====================== ---------------------------------|------------------|----------------------------------------- $$$$$$$$$$ | | $ kerenl $ | | $$$$$$$$$$ | | | | | | V V ============ ============ | ... | | ... | ============ ============ | | V | ============ | | TCP/IP | | ============ | | | V V ======================================== | GLDv3 | |======================================= _________________________________| | | V V ================== ========================================= | | |[1] | | | | GLDv3 Callback functions registered | | Net80211 | ========================= by | | module | | | driver | | | V | | | |======================== | | | Functions exported by net80211 | | | | | | | ========================================== ================= | | V | +----------------------------------+ | |[2] | | | Net80211 Callback functions | | | registered by LLD | | +----------------------------------+ | | | V v +-----------------------------------------------------------+ |[3] | | LLD Internal functions | | | +-----------------------------------------------------------+ ^ --------------------------------------------------------------------------------------------- $$$$$$$$$$$$$$ ^ $ hardware $ | interrupt from hardware $$$$$$$$$$$$$$ | The short description of each part is as below: [1]: GLD callback functions, which calls nto LLD for driver specific operations. [2]: Net80211 callback functions registered by LLD, which calls into LLD for H/W related functions needed by net80211. [3]: LLD Internal functions, which are responsible for allocating descriptor/buffer, handling interrupt and other 802.11 parameter regulating related operations. Specially for 4965 driver, this part is where the firmware focuses on. 2.2 data flow chart In general, In terms of the directions of the data flows, there are two kinds of chart. One is Tx direction, including send data frame produced by TCP/IP, send management frame produced by net80211 module, and config the 802.11 parameters on the card. The chart is illustrated as following(the arrows represent the data flow direction): | V | ============ | | TCP/IP | | ============ | | | V V ======================================== | GLDv3 | |======================================= _________________________________| | | V V ================== ========================================= | | |[1] | | | | GLDv3 Callback functions registered | | Net80211 | ========================= by | | module | | config 802.11 | driver | | | V parameters | | | |======================== | | | Functions exported by net80211 | | | | | | | ========================================== ================= | | V | +----------------------------------+ | |[2] | | | Net80211 Callback functions | | send data | registered by LLD | | +----------------------------------+ | | send management frame | V v +-----------------------------------------------------------+ |[3] | | LLD Internal functions | | | +-----------------------------------------------------------+ The other is Rx direction, including reveive date and management frame from hardware and send upwards to the net80211 module, and report link status to GLDv3. The chart is illustrated as following(the arrows represent the data flow direction): | ^ | ============ | | TCP/IP | | ============ | | | ^ ^ ======================================== | GLDv3 | |======================================= | | ^ ================== ========================================= | | |[1] | | | | GLDv3 Callback functions registered | | Net80211 | ========================= by | | module | | | driver | | | V | | | |======================== | | | Functions exported by net80211 | | | | | | | ========================================== ================= | | ^ | +----------------------------------+ | |[2] | | | Net80211 Callback functions | | | registered by LLD | | report link status +----------------------------------+ | | | | reveive data and management | ^ frame ^ +-----------------------------------------------------------+ |[3] | | LLD Internal functions | | | +-----------------------------------------------------------+ ^ | from hardware 3. The detailed info in wifi driver 3.1 General driver functions 3.1.1 int xxx_attach(dev_info_t *dip, ddi_attach_cmd_t cmd); allocate resource, such as memory, dma, register interrupt, initialize mutex, initialize hardware, register callback functions to GLD and net80211 etc. 3.1.2 int xxx_detach(dev_info_t *dip, ddi_detach_cmd_t cmd); free what allocated in _attach(), unregister what registered in _attach() 3.1.3 uint_t xxx_intr(caddr_t); deal with interrupt. 3.2 GLD callback functions The prototypes of each function registered to GLD are listed below: 3.2.1 int xxx_m_stat(void *arg, uint_t stat, uint64_t *val); collecting kerenl statictics info from the driver 3.2.2 int xxx_m_start(void *arg); Initializing the hardware, enable the interrupt and start the running of the hardware. 3.2.3 void xxx_m_stop(void *arg); disable interrupt and stop the running of the hardware 3.2.4 int xxx_m_unicst(void *arg, const uint8_t *macaddr); set unicast mac address 3.2.5 int xxx_m_multicst(void *arg, boolean_t add, const uint8_t *m); set multicast mac address 3.2.6 int xxx_m_promisc(void *arg, boolean_t on); set promiscious mode 3.2.7 mblk_t *xxx_m_tx(void *arg, mblk_t *mp); send data and management frame to the hardware 3.2.8 void xxx_m_ioctl(void *arg, queue_t *wq, mblk_t *mp); config 802.11 parameters 3.3 Net80211 callback functions 3.3.1 xxx_ic_xmit() used to send management frames produced by net80211 module to the hardware. 3.3.2 int xxx_newstate(ieee80211com_t *ic, enum ieee80211_state nstate, int arg) used to do wifi driver special operations when the state machine transacts, for example, change the current channel of the wifi card. 3.3.3 others 3.4 LLD functions This part varies from hardware to hardware, and always need spending most of the efforts when we develop a new wifi driver. For the 4965 wifi driver, this part should be the most key part that need close collaboration between Intel and Sun engineers. 4. reference Writing Device Drivers http://docs.sun.com/app/docs/doc/805-7378?q=writing+device+drivers