drivers: power: report battery voltage in AOSP compatible format
[GitHub/mt8127/android_kernel_alcatel_ttab.git] / net / sctp / primitive.c
CommitLineData
60c778b2 1/* SCTP kernel implementation
1da177e4
LT
2 * Copyright (c) 1999-2000 Cisco, Inc.
3 * Copyright (c) 1999-2001 Motorola, Inc.
4 *
60c778b2 5 * This file is part of the SCTP kernel implementation
1da177e4
LT
6 *
7 * These functions implement the SCTP primitive functions from Section 10.
8 *
9 * Note that the descriptions from the specification are USER level
10 * functions--this file is the functions which populate the struct proto
11 * for SCTP which is the BOTTOM of the sockets interface.
12 *
60c778b2 13 * This SCTP implementation is free software;
1da177e4
LT
14 * you can redistribute it and/or modify it under the terms of
15 * the GNU General Public License as published by
16 * the Free Software Foundation; either version 2, or (at your option)
17 * any later version.
18 *
60c778b2 19 * This SCTP implementation is distributed in the hope that it
1da177e4
LT
20 * will be useful, but WITHOUT ANY WARRANTY; without even the implied
21 * ************************
22 * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
23 * See the GNU General Public License for more details.
24 *
25 * You should have received a copy of the GNU General Public License
26 * along with GNU CC; see the file COPYING. If not, write to
27 * the Free Software Foundation, 59 Temple Place - Suite 330,
28 * Boston, MA 02111-1307, USA.
29 *
30 * Please send any bug reports or fixes you make to the
31 * email address(es):
32 * lksctp developers <lksctp-developers@lists.sourceforge.net>
33 *
34 * Or submit a bug report through the following website:
35 * http://www.sf.net/projects/lksctp
36 *
37 * Written or modified by:
38 * La Monte H.P. Yarroll <piggy@acm.org>
39 * Narasimha Budihal <narasimha@refcode.org>
40 * Karl Knutson <karl@athena.chicago.il.us>
41 * Ardelle Fan <ardelle.fan@intel.com>
42 * Kevin Gao <kevin.gao@intel.com>
43 *
44 * Any bugs reported given to us we will try to fix... any fixes shared will
45 * be incorporated into the next SCTP release.
46 */
47
48#include <linux/types.h>
49#include <linux/list.h> /* For struct list_head */
50#include <linux/socket.h>
51#include <linux/ip.h>
52#include <linux/time.h> /* For struct timeval */
5a0e3ad6 53#include <linux/gfp.h>
1da177e4
LT
54#include <net/sock.h>
55#include <net/sctp/sctp.h>
56#include <net/sctp/sm.h>
57
58#define DECLARE_PRIMITIVE(name) \
59/* This is called in the code as sctp_primitive_ ## name. */ \
55e26eb9 60int sctp_primitive_ ## name(struct net *net, struct sctp_association *asoc, \
1da177e4
LT
61 void *arg) { \
62 int error = 0; \
63 sctp_event_t event_type; sctp_subtype_t subtype; \
64 sctp_state_t state; \
65 struct sctp_endpoint *ep; \
66 \
67 event_type = SCTP_EVENT_T_PRIMITIVE; \
68 subtype = SCTP_ST_PRIMITIVE(SCTP_PRIMITIVE_ ## name); \
69 state = asoc ? asoc->state : SCTP_STATE_CLOSED; \
70 ep = asoc ? asoc->ep : NULL; \
71 \
55e26eb9 72 error = sctp_do_sm(net, event_type, subtype, state, ep, asoc, \
1da177e4 73 arg, GFP_KERNEL); \
d808ad9a 74 return error; \
1da177e4
LT
75}
76
77/* 10.1 ULP-to-SCTP
78 * B) Associate
79 *
80 * Format: ASSOCIATE(local SCTP instance name, destination transport addr,
81 * outbound stream count)
82 * -> association id [,destination transport addr list] [,outbound stream
83 * count]
84 *
85 * This primitive allows the upper layer to initiate an association to a
86 * specific peer endpoint.
87 *
88 * This version assumes that asoc is fully populated with the initial
89 * parameters. We then return a traditional kernel indicator of
90 * success or failure.
91 */
92
93/* This is called in the code as sctp_primitive_ASSOCIATE. */
94
95DECLARE_PRIMITIVE(ASSOCIATE)
96
97/* 10.1 ULP-to-SCTP
98 * C) Shutdown
99 *
100 * Format: SHUTDOWN(association id)
101 * -> result
102 *
103 * Gracefully closes an association. Any locally queued user data
104 * will be delivered to the peer. The association will be terminated only
105 * after the peer acknowledges all the SCTP packets sent. A success code
106 * will be returned on successful termination of the association. If
107 * attempting to terminate the association results in a failure, an error
108 * code shall be returned.
109 */
110
111DECLARE_PRIMITIVE(SHUTDOWN);
112
113/* 10.1 ULP-to-SCTP
114 * C) Abort
115 *
116 * Format: Abort(association id [, cause code])
117 * -> result
118 *
119 * Ungracefully closes an association. Any locally queued user data
120 * will be discarded and an ABORT chunk is sent to the peer. A success
121 * code will be returned on successful abortion of the association. If
122 * attempting to abort the association results in a failure, an error
123 * code shall be returned.
124 */
125
126DECLARE_PRIMITIVE(ABORT);
127
128/* 10.1 ULP-to-SCTP
129 * E) Send
130 *
131 * Format: SEND(association id, buffer address, byte count [,context]
132 * [,stream id] [,life time] [,destination transport address]
133 * [,unorder flag] [,no-bundle flag] [,payload protocol-id] )
134 * -> result
135 *
136 * This is the main method to send user data via SCTP.
137 *
138 * Mandatory attributes:
139 *
140 * o association id - local handle to the SCTP association
141 *
142 * o buffer address - the location where the user message to be
143 * transmitted is stored;
144 *
145 * o byte count - The size of the user data in number of bytes;
146 *
147 * Optional attributes:
148 *
149 * o context - an optional 32 bit integer that will be carried in the
150 * sending failure notification to the ULP if the transportation of
151 * this User Message fails.
152 *
153 * o stream id - to indicate which stream to send the data on. If not
154 * specified, stream 0 will be used.
155 *
156 * o life time - specifies the life time of the user data. The user data
157 * will not be sent by SCTP after the life time expires. This
158 * parameter can be used to avoid efforts to transmit stale
159 * user messages. SCTP notifies the ULP if the data cannot be
160 * initiated to transport (i.e. sent to the destination via SCTP's
161 * send primitive) within the life time variable. However, the
162 * user data will be transmitted if SCTP has attempted to transmit a
163 * chunk before the life time expired.
164 *
165 * o destination transport address - specified as one of the destination
166 * transport addresses of the peer endpoint to which this packet
167 * should be sent. Whenever possible, SCTP should use this destination
168 * transport address for sending the packets, instead of the current
169 * primary path.
170 *
171 * o unorder flag - this flag, if present, indicates that the user
172 * would like the data delivered in an unordered fashion to the peer
173 * (i.e., the U flag is set to 1 on all DATA chunks carrying this
174 * message).
175 *
176 * o no-bundle flag - instructs SCTP not to bundle this user data with
177 * other outbound DATA chunks. SCTP MAY still bundle even when
178 * this flag is present, when faced with network congestion.
179 *
180 * o payload protocol-id - A 32 bit unsigned integer that is to be
181 * passed to the peer indicating the type of payload protocol data
182 * being transmitted. This value is passed as opaque data by SCTP.
183 */
184
185DECLARE_PRIMITIVE(SEND);
186
187/* 10.1 ULP-to-SCTP
188 * J) Request Heartbeat
189 *
190 * Format: REQUESTHEARTBEAT(association id, destination transport address)
191 *
192 * -> result
193 *
194 * Instructs the local endpoint to perform a HeartBeat on the specified
195 * destination transport address of the given association. The returned
196 * result should indicate whether the transmission of the HEARTBEAT
197 * chunk to the destination address is successful.
198 *
199 * Mandatory attributes:
200 *
201 * o association id - local handle to the SCTP association
202 *
203 * o destination transport address - the transport address of the
204 * association on which a heartbeat should be issued.
205 */
206
207DECLARE_PRIMITIVE(REQUESTHEARTBEAT);
208
209/* ADDIP
210* 3.1.1 Address Configuration Change Chunk (ASCONF)
d808ad9a 211*
1da177e4
LT
212* This chunk is used to communicate to the remote endpoint one of the
213* configuration change requests that MUST be acknowledged. The
214* information carried in the ASCONF Chunk uses the form of a
215* Type-Length-Value (TLV), as described in "3.2.1 Optional/
216* Variable-length Parameter Format" in RFC2960 [5], forall variable
217* parameters.
218*/
219
220DECLARE_PRIMITIVE(ASCONF);