summaryrefslogtreecommitdiffstats
path: root/Documentation/networking/caif/Linux-CAIF.txt
blob: 7fe7a9a33a4f5fd1a1cbbd48f8c3b41347c25572 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
Linux CAIF
===========
copyright (C) ST-Ericsson AB 2010
Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
License terms: GNU General Public License (GPL) version 2


Introduction
------------
CAIF is a MUX protocol used by ST-Ericsson cellular modems for
communication between Modem and host. The host processes can open virtual AT
channels, initiate GPRS Data connections, Video channels and Utility Channels.
The Utility Channels are general purpose pipes between modem and host.

ST-Ericsson modems support a number of transports between modem
and host. Currently, UART and Loopback are available for Linux.


Architecture:
------------
The implementation of CAIF is divided into:
* CAIF Socket Layer, Kernel API, and  Net Device.
* CAIF Core Protocol Implementation
* CAIF Link Layer, implemented as NET devices.


  RTNL
   !
   !	 +------+   +------+   +------+
   !	+------+!  +------+!  +------+!
   !	! Sock !!  !Kernel!!  ! Net  !!
   !	! API  !+  ! API  !+  ! Dev  !+	  <- CAIF Client APIs
   !	+------+   +------!   +------+
   !	   !	      !		 !
   !	   +----------!----------+
   !		   +------+		  <- CAIF Protocol Implementation
   +------->	   ! CAIF !
		   ! Core !
		   +------+
	     +--------!--------+
	     !		       !
	  +------+	    +-----+
	  !    	 !	    ! TTY !	  <- Link Layer (Net Devices)
	  +------+	    +-----+


Using the Kernel API
----------------------
The Kernel API is used for accessing CAIF channels from the
kernel.
The user of the API has to implement two callbacks for receive
and control.
The receive callback gives a CAIF packet as a SKB. The control
callback will
notify of channel initialization complete, and flow-on/flow-
off.


  struct caif_device caif_dev = {
    .caif_config = {
     .name = "MYDEV"
     .type = CAIF_CHTY_AT
    }
   .receive_cb = my_receive,
   .control_cb = my_control,
  };
  caif_add_device(&caif_dev);
  caif_transmit(&caif_dev, skb);

See the caif_kernel.h for details about the CAIF kernel API.


I M P L E M E N T A T I O N
===========================
===========================

CAIF Core Protocol Layer
=========================================

CAIF Core layer implements the CAIF protocol as defined by ST-Ericsson.
It implements the CAIF protocol stack in a layered approach, where
each layer described in the specification is implemented as a separate layer.
The architecture is inspired by the design patterns "Protocol Layer" and
"Protocol Packet".

== CAIF structure ==
The Core CAIF implementation contains:
      -	Simple implementation of CAIF.
      -	Layered architecture (a la Streams), each layer in the CAIF
	specification is implemented in a separate c-file.
      -	Clients must implement PHY layer to access physical HW
	with receive and transmit functions.
      -	Clients must call configuration function to add PHY layer.
      -	Clients must implement CAIF layer to consume/produce
	CAIF payload with receive and transmit functions.
      -	Clients must call configuration function to add and connect the
	Client layer.
      - When receiving / transmitting CAIF Packets (cfpkt), ownership is passed
	to the called function (except for framing layers' receive functions
	or if a transmit function returns an error, in which case the caller
	must free the packet).

Layered Architecture
--------------------
The CAIF protocol can be divided into two parts: Support functions and Protocol
Implementation. The support functions include:

      - CFPKT CAIF Packet. Implementation of CAIF Protocol Packet. The
	CAIF Packet has functions for creating, destroying and adding content
	and for adding/extracting header and trailers to protocol packets.

      - CFLST CAIF list implementation.

      - CFGLUE CAIF Glue. Contains OS Specifics, such as memory
	allocation, endianness, etc.

The CAIF Protocol implementation contains:

      - CFCNFG CAIF Configuration layer. Configures the CAIF Protocol
	Stack and provides a Client interface for adding Link-Layer and
	Driver interfaces on top of the CAIF Stack.

      - CFCTRL CAIF Control layer. Encodes and Decodes control messages
	such as enumeration and channel setup. Also matches request and
	response messages.

      - CFSERVL General CAIF Service Layer functionality; handles flow
	control and remote shutdown requests.

      - CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual
        External Interface). This layer encodes/decodes VEI frames.

      - CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP
	traffic), encodes/decodes Datagram frames.

      - CFMUX CAIF Mux layer. Handles multiplexing between multiple
	physical bearers and multiple channels such as VEI, Datagram, etc.
	The MUX keeps track of the existing CAIF Channels and
	Physical Instances and selects the apropriate instance based
	on Channel-Id and Physical-ID.

      - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length
	and frame checksum.

      - CFSERL CAIF Serial layer. Handles concatenation/split of frames
	into CAIF Frames with correct length.



		    +---------+
		    | Config  |
		    | CFCNFG  |
		    +---------+
			 !
    +---------+	    +---------+	    +---------+
    |	AT    |	    | Control |	    | Datagram|
    | CFVEIL  |	    | CFCTRL  |	    | CFDGML  |
    +---------+	    +---------+	    +---------+
	   \_____________!______________/
			 !
		    +---------+
		    |	MUX   |
		    |	      |
		    +---------+
		    _____!_____
		   /	       \
	    +---------+	    +---------+
	    | CFFRML  |	    | CFFRML  |
	    | Framing |	    | Framing |
	    +---------+	    +---------+
		 !		!
	    +---------+	    +---------+
	    |         |	    | Serial  |
	    |	      |	    | CFSERL  |
	    +---------+	    +---------+


In this layered approach the following "rules" apply.
      - All layers embed the same structure "struct cflayer"
      - A layer does not depend on any other layer's private data.
      - Layers are stacked by setting the pointers
		  layer->up , layer->dn
      -	In order to send data upwards, each layer should do
		 layer->up->receive(layer->up, packet);
      - In order to send data downwards, each layer should do
		 layer->dn->transmit(layer->dn, packet);


Linux Driver Implementation
===========================

Linux GPRS Net Device and CAIF socket are implemented on top of the
CAIF Core protocol. The Net device and CAIF socket have an instance of
'struct cflayer', just like the CAIF Core protocol stack.
Net device and Socket implement the 'receive()' function defined by
'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and
receive of packets is handled as by the rest of the layers: the 'dn->transmit()'
function is called in order to transmit data.

The layer on top of the CAIF Core implementation is
sometimes referred to as the "Client layer".


Configuration of Link Layer
---------------------------
The Link Layer is implemented as Linux net devices (struct net_device).
Payload handling and registration is done using standard Linux mechanisms.

The CAIF Protocol relies on a loss-less link layer without implementing
retransmission. This implies that packet drops must not happen.
Therefore a flow-control mechanism is implemented where the physical
interface can initiate flow stop for all CAIF Channels.
OpenPOWER on IntegriCloud