|
1 /* |
|
2 * Linux WiMAX |
|
3 * Kernel space API for accessing WiMAX devices |
|
4 * |
|
5 * |
|
6 * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com> |
|
7 * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> |
|
8 * |
|
9 * This program is free software; you can redistribute it and/or |
|
10 * modify it under the terms of the GNU General Public License version |
|
11 * 2 as published by the Free Software Foundation. |
|
12 * |
|
13 * This program is distributed in the hope that it will be useful, |
|
14 * but WITHOUT ANY WARRANTY; without even the implied warranty of |
|
15 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
|
16 * GNU General Public License for more details. |
|
17 * |
|
18 * You should have received a copy of the GNU General Public License |
|
19 * along with this program; if not, write to the Free Software |
|
20 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
|
21 * 02110-1301, USA. |
|
22 * |
|
23 * |
|
24 * The WiMAX stack provides an API for controlling and managing the |
|
25 * system's WiMAX devices. This API affects the control plane; the |
|
26 * data plane is accessed via the network stack (netdev). |
|
27 * |
|
28 * Parts of the WiMAX stack API and notifications are exported to |
|
29 * user space via Generic Netlink. In user space, libwimax (part of |
|
30 * the wimax-tools package) provides a shim layer for accessing those |
|
31 * calls. |
|
32 * |
|
33 * The API is standarized for all WiMAX devices and different drivers |
|
34 * implement the backend support for it. However, device-specific |
|
35 * messaging pipes are provided that can be used to issue commands and |
|
36 * receive notifications in free form. |
|
37 * |
|
38 * Currently the messaging pipes are the only means of control as it |
|
39 * is not known (due to the lack of more devices in the market) what |
|
40 * will be a good abstraction layer. Expect this to change as more |
|
41 * devices show in the market. This API is designed to be growable in |
|
42 * order to address this problem. |
|
43 * |
|
44 * USAGE |
|
45 * |
|
46 * Embed a `struct wimax_dev` at the beginning of the the device's |
|
47 * private structure, initialize and register it. For details, see |
|
48 * `struct wimax_dev`s documentation. |
|
49 * |
|
50 * Once this is done, wimax-tools's libwimaxll can be used to |
|
51 * communicate with the driver from user space. You user space |
|
52 * application does not have to forcibily use libwimaxll and can talk |
|
53 * the generic netlink protocol directly if desired. |
|
54 * |
|
55 * Remember this is a very low level API that will to provide all of |
|
56 * WiMAX features. Other daemons and services running in user space |
|
57 * are the expected clients of it. They offer a higher level API that |
|
58 * applications should use (an example of this is the Intel's WiMAX |
|
59 * Network Service for the i2400m). |
|
60 * |
|
61 * DESIGN |
|
62 * |
|
63 * Although not set on final stone, this very basic interface is |
|
64 * mostly completed. Remember this is meant to grow as new common |
|
65 * operations are decided upon. New operations will be added to the |
|
66 * interface, intent being on keeping backwards compatibility as much |
|
67 * as possible. |
|
68 * |
|
69 * This layer implements a set of calls to control a WiMAX device, |
|
70 * exposing a frontend to the rest of the kernel and user space (via |
|
71 * generic netlink) and a backend implementation in the driver through |
|
72 * function pointers. |
|
73 * |
|
74 * WiMAX devices have a state, and a kernel-only API allows the |
|
75 * drivers to manipulate that state. State transitions are atomic, and |
|
76 * only some of them are allowed (see `enum wimax_st`). |
|
77 * |
|
78 * Most API calls will set the state automatically; in most cases |
|
79 * drivers have to only report state changes due to external |
|
80 * conditions. |
|
81 * |
|
82 * All API operations are 'atomic', serialized thorough a mutex in the |
|
83 * `struct wimax_dev`. |
|
84 * |
|
85 * EXPORTING TO USER SPACE THROUGH GENERIC NETLINK |
|
86 * |
|
87 * The API is exported to user space using generic netlink (other |
|
88 * methods can be added as needed). |
|
89 * |
|
90 * There is a Generic Netlink Family named "WiMAX", where interfaces |
|
91 * supporting the WiMAX interface receive commands and broadcast their |
|
92 * signals over a multicast group named "msg". |
|
93 * |
|
94 * Mapping to the source/destination interface is done by an interface |
|
95 * index attribute. |
|
96 * |
|
97 * For user-to-kernel traffic (commands) we use a function call |
|
98 * marshalling mechanism, where a message X with attributes A, B, C |
|
99 * sent from user space to kernel space means executing the WiMAX API |
|
100 * call wimax_X(A, B, C), sending the results back as a message. |
|
101 * |
|
102 * Kernel-to-user (notifications or signals) communication is sent |
|
103 * over multicast groups. This allows to have multiple applications |
|
104 * monitoring them. |
|
105 * |
|
106 * Each command/signal gets assigned it's own attribute policy. This |
|
107 * way the validator will verify that all the attributes in there are |
|
108 * only the ones that should be for each command/signal. Thing of an |
|
109 * attribute mapping to a type+argumentname for each command/signal. |
|
110 * |
|
111 * If we had a single policy for *all* commands/signals, after running |
|
112 * the validator we'd have to check "does this attribute belong in |
|
113 * here"? for each one. It can be done manually, but it's just easier |
|
114 * to have the validator do that job with multiple policies. As well, |
|
115 * it makes it easier to later expand each command/signal signature |
|
116 * without affecting others and keeping the namespace more or less |
|
117 * sane. Not that it is too complicated, but it makes it even easier. |
|
118 * |
|
119 * No state information is maintained in the kernel for each user |
|
120 * space connection (the connection is stateless). |
|
121 * |
|
122 * TESTING FOR THE INTERFACE AND VERSIONING |
|
123 * |
|
124 * If network interface X is a WiMAX device, there will be a Generic |
|
125 * Netlink family named "WiMAX X" and the device will present a |
|
126 * "wimax" directory in it's network sysfs directory |
|
127 * (/sys/class/net/DEVICE/wimax) [used by HAL]. |
|
128 * |
|
129 * The inexistence of any of these means the device does not support |
|
130 * this WiMAX API. |
|
131 * |
|
132 * By querying the generic netlink controller, versioning information |
|
133 * and the multicast groups available can be found. Applications using |
|
134 * the interface can either rely on that or use the generic netlink |
|
135 * controller to figure out which generic netlink commands/signals are |
|
136 * supported. |
|
137 * |
|
138 * NOTE: this versioning is a last resort to avoid hard |
|
139 * incompatibilities. It is the intention of the design of this |
|
140 * stack not to introduce backward incompatible changes. |
|
141 * |
|
142 * The version code has to fit in one byte (restrictions imposed by |
|
143 * generic netlink); we use `version / 10` for the major version and |
|
144 * `version % 10` for the minor. This gives 9 minors for each major |
|
145 * and 25 majors. |
|
146 * |
|
147 * The version change protocol is as follow: |
|
148 * |
|
149 * - Major versions: needs to be increased if an existing message/API |
|
150 * call is changed or removed. Doesn't need to be changed if a new |
|
151 * message is added. |
|
152 * |
|
153 * - Minor version: needs to be increased if new messages/API calls are |
|
154 * being added or some other consideration that doesn't impact the |
|
155 * user-kernel interface too much (like some kind of bug fix) and |
|
156 * that is kind of left up in the air to common sense. |
|
157 * |
|
158 * User space code should not try to work if the major version it was |
|
159 * compiled for differs from what the kernel offers. As well, if the |
|
160 * minor version of the kernel interface is lower than the one user |
|
161 * space is expecting (the one it was compiled for), the kernel |
|
162 * might be missing API calls; user space shall be ready to handle |
|
163 * said condition. Use the generic netlink controller operations to |
|
164 * find which ones are supported and which not. |
|
165 * |
|
166 * libwimaxll:wimaxll_open() takes care of checking versions. |
|
167 * |
|
168 * THE OPERATIONS: |
|
169 * |
|
170 * Each operation is defined in its on file (drivers/net/wimax/op-*.c) |
|
171 * for clarity. The parts needed for an operation are: |
|
172 * |
|
173 * - a function pointer in `struct wimax_dev`: optional, as the |
|
174 * operation might be implemented by the stack and not by the |
|
175 * driver. |
|
176 * |
|
177 * All function pointers are named wimax_dev->op_*(), and drivers |
|
178 * must implement them except where noted otherwise. |
|
179 * |
|
180 * - When exported to user space, a `struct nla_policy` to define the |
|
181 * attributes of the generic netlink command and a `struct genl_ops` |
|
182 * to define the operation. |
|
183 * |
|
184 * All the declarations for the operation codes (WIMAX_GNL_OP_<NAME>) |
|
185 * and generic netlink attributes (WIMAX_GNL_<NAME>_*) are declared in |
|
186 * include/linux/wimax.h; this file is intended to be cloned by user |
|
187 * space to gain access to those declarations. |
|
188 * |
|
189 * A few caveats to remember: |
|
190 * |
|
191 * - Need to define attribute numbers starting in 1; otherwise it |
|
192 * fails. |
|
193 * |
|
194 * - the `struct genl_family` requires a maximum attribute id; when |
|
195 * defining the `struct nla_policy` for each message, it has to have |
|
196 * an array size of WIMAX_GNL_ATTR_MAX+1. |
|
197 * |
|
198 * THE PIPE INTERFACE: |
|
199 * |
|
200 * This interface is kept intentionally simple. The driver can send |
|
201 * and receive free-form messages to/from user space through a |
|
202 * pipe. See drivers/net/wimax/op-msg.c for details. |
|
203 * |
|
204 * The kernel-to-user messages are sent with |
|
205 * wimax_msg(). user-to-kernel messages are delivered via |
|
206 * wimax_dev->op_msg_from_user(). |
|
207 * |
|
208 * RFKILL: |
|
209 * |
|
210 * RFKILL support is built into the wimax_dev layer; the driver just |
|
211 * needs to call wimax_report_rfkill_{hw,sw}() to inform of changes in |
|
212 * the hardware or software RF kill switches. When the stack wants to |
|
213 * turn the radio off, it will call wimax_dev->op_rfkill_sw_toggle(), |
|
214 * which the driver implements. |
|
215 * |
|
216 * User space can set the software RF Kill switch by calling |
|
217 * wimax_rfkill(). |
|
218 * |
|
219 * The code for now only supports devices that don't require polling; |
|
220 * If the device needs to be polled, create a self-rearming delayed |
|
221 * work struct for polling or look into adding polled support to the |
|
222 * WiMAX stack. |
|
223 * |
|
224 * When initializing the hardware (_probe), after calling |
|
225 * wimax_dev_add(), query the device for it's RF Kill switches status |
|
226 * and feed it back to the WiMAX stack using |
|
227 * wimax_report_rfkill_{hw,sw}(). If any switch is missing, always |
|
228 * report it as ON. |
|
229 * |
|
230 * NOTE: the wimax stack uses an inverted terminology to that of the |
|
231 * RFKILL subsystem: |
|
232 * |
|
233 * - ON: radio is ON, RFKILL is DISABLED or OFF. |
|
234 * - OFF: radio is OFF, RFKILL is ENABLED or ON. |
|
235 * |
|
236 * MISCELLANEOUS OPS: |
|
237 * |
|
238 * wimax_reset() can be used to reset the device to power on state; by |
|
239 * default it issues a warm reset that maintains the same device |
|
240 * node. If that is not possible, it falls back to a cold reset |
|
241 * (device reconnect). The driver implements the backend to this |
|
242 * through wimax_dev->op_reset(). |
|
243 */ |
|
244 |
|
245 #ifndef __NET__WIMAX_H__ |
|
246 #define __NET__WIMAX_H__ |
|
247 #ifdef __KERNEL__ |
|
248 |
|
249 #include <linux/wimax.h> |
|
250 #include <net/genetlink.h> |
|
251 #include <linux/netdevice.h> |
|
252 |
|
253 struct net_device; |
|
254 struct genl_info; |
|
255 struct wimax_dev; |
|
256 struct input_dev; |
|
257 |
|
258 /** |
|
259 * struct wimax_dev - Generic WiMAX device |
|
260 * |
|
261 * @net_dev: [fill] Pointer to the &struct net_device this WiMAX |
|
262 * device implements. |
|
263 * |
|
264 * @op_msg_from_user: [fill] Driver-specific operation to |
|
265 * handle a raw message from user space to the driver. The |
|
266 * driver can send messages to user space using with |
|
267 * wimax_msg_to_user(). |
|
268 * |
|
269 * @op_rfkill_sw_toggle: [fill] Driver-specific operation to act on |
|
270 * userspace (or any other agent) requesting the WiMAX device to |
|
271 * change the RF Kill software switch (WIMAX_RF_ON or |
|
272 * WIMAX_RF_OFF). |
|
273 * If such hardware support is not present, it is assumed the |
|
274 * radio cannot be switched off and it is always on (and the stack |
|
275 * will error out when trying to switch it off). In such case, |
|
276 * this function pointer can be left as NULL. |
|
277 * |
|
278 * @op_reset: [fill] Driver specific operation to reset the |
|
279 * device. |
|
280 * This operation should always attempt first a warm reset that |
|
281 * does not disconnect the device from the bus and return 0. |
|
282 * If that fails, it should resort to some sort of cold or bus |
|
283 * reset (even if it implies a bus disconnection and device |
|
284 * dissapearance). In that case, -ENODEV should be returned to |
|
285 * indicate the device is gone. |
|
286 * This operation has to be synchronous, and return only when the |
|
287 * reset is complete. In case of having had to resort to bus/cold |
|
288 * reset implying a device disconnection, the call is allowed to |
|
289 * return inmediately. |
|
290 * NOTE: wimax_dev->mutex is NOT locked when this op is being |
|
291 * called; however, wimax_dev->mutex_reset IS locked to ensure |
|
292 * serialization of calls to wimax_reset(). |
|
293 * See wimax_reset()'s documentation. |
|
294 * |
|
295 * @name: [fill] A way to identify this device. We need to register a |
|
296 * name with many subsystems (input for RFKILL, workqueue |
|
297 * creation, etc). We can't use the network device name as that |
|
298 * might change and in some instances we don't know it yet (until |
|
299 * we don't call register_netdev()). So we generate an unique one |
|
300 * using the driver name and device bus id, place it here and use |
|
301 * it across the board. Recommended naming: |
|
302 * DRIVERNAME-BUSNAME:BUSID (dev->bus->name, dev->bus_id). |
|
303 * |
|
304 * @id_table_node: [private] link to the list of wimax devices kept by |
|
305 * id-table.c. Protected by it's own spinlock. |
|
306 * |
|
307 * @mutex: [private] Serializes all concurrent access and execution of |
|
308 * operations. |
|
309 * |
|
310 * @mutex_reset: [private] Serializes reset operations. Needs to be a |
|
311 * different mutex because as part of the reset operation, the |
|
312 * driver has to call back into the stack to do things such as |
|
313 * state change, that require wimax_dev->mutex. |
|
314 * |
|
315 * @state: [private] Current state of the WiMAX device. |
|
316 * |
|
317 * @rfkill: [private] integration into the RF-Kill infrastructure. |
|
318 * |
|
319 * @rfkill_input: [private] virtual input device to process the |
|
320 * hardware RF Kill switches. |
|
321 * |
|
322 * @rf_sw: [private] State of the software radio switch (OFF/ON) |
|
323 * |
|
324 * @rf_hw: [private] State of the hardware radio switch (OFF/ON) |
|
325 * |
|
326 * @debugfs_dentry: [private] Used to hook up a debugfs entry. This |
|
327 * shows up in the debugfs root as wimax\:DEVICENAME. |
|
328 * |
|
329 * Description: |
|
330 * This structure defines a common interface to access all WiMAX |
|
331 * devices from different vendors and provides a common API as well as |
|
332 * a free-form device-specific messaging channel. |
|
333 * |
|
334 * Usage: |
|
335 * 1. Embed a &struct wimax_dev at *the beginning* the network |
|
336 * device structure so that netdev_priv() points to it. |
|
337 * |
|
338 * 2. memset() it to zero |
|
339 * |
|
340 * 3. Initialize with wimax_dev_init(). This will leave the WiMAX |
|
341 * device in the %__WIMAX_ST_NULL state. |
|
342 * |
|
343 * 4. Fill all the fields marked with [fill]; once called |
|
344 * wimax_dev_add(), those fields CANNOT be modified. |
|
345 * |
|
346 * 5. Call wimax_dev_add() *after* registering the network |
|
347 * device. This will leave the WiMAX device in the %WIMAX_ST_DOWN |
|
348 * state. |
|
349 * Protect the driver's net_device->open() against succeeding if |
|
350 * the wimax device state is lower than %WIMAX_ST_DOWN. |
|
351 * |
|
352 * 6. Select when the device is going to be turned on/initialized; |
|
353 * for example, it could be initialized on 'ifconfig up' (when the |
|
354 * netdev op 'open()' is called on the driver). |
|
355 * |
|
356 * When the device is initialized (at `ifconfig up` time, or right |
|
357 * after calling wimax_dev_add() from _probe(), make sure the |
|
358 * following steps are taken |
|
359 * |
|
360 * a. Move the device to %WIMAX_ST_UNINITIALIZED. This is needed so |
|
361 * some API calls that shouldn't work until the device is ready |
|
362 * can be blocked. |
|
363 * |
|
364 * b. Initialize the device. Make sure to turn the SW radio switch |
|
365 * off and move the device to state %WIMAX_ST_RADIO_OFF when |
|
366 * done. When just initialized, a device should be left in RADIO |
|
367 * OFF state until user space devices to turn it on. |
|
368 * |
|
369 * c. Query the device for the state of the hardware rfkill switch |
|
370 * and call wimax_rfkill_report_hw() and wimax_rfkill_report_sw() |
|
371 * as needed. See below. |
|
372 * |
|
373 * wimax_dev_rm() undoes before unregistering the network device. Once |
|
374 * wimax_dev_add() is called, the driver can get called on the |
|
375 * wimax_dev->op_* function pointers |
|
376 * |
|
377 * CONCURRENCY: |
|
378 * |
|
379 * The stack provides a mutex for each device that will disallow API |
|
380 * calls happening concurrently; thus, op calls into the driver |
|
381 * through the wimax_dev->op*() function pointers will always be |
|
382 * serialized and *never* concurrent. |
|
383 * |
|
384 * For locking, take wimax_dev->mutex is taken; (most) operations in |
|
385 * the API have to check for wimax_dev_is_ready() to return 0 before |
|
386 * continuing (this is done internally). |
|
387 * |
|
388 * REFERENCE COUNTING: |
|
389 * |
|
390 * The WiMAX device is reference counted by the associated network |
|
391 * device. The only operation that can be used to reference the device |
|
392 * is wimax_dev_get_by_genl_info(), and the reference it acquires has |
|
393 * to be released with dev_put(wimax_dev->net_dev). |
|
394 * |
|
395 * RFKILL: |
|
396 * |
|
397 * At startup, both HW and SW radio switchess are assumed to be off. |
|
398 * |
|
399 * At initialization time [after calling wimax_dev_add()], have the |
|
400 * driver query the device for the status of the software and hardware |
|
401 * RF kill switches and call wimax_report_rfkill_hw() and |
|
402 * wimax_rfkill_report_sw() to indicate their state. If any is |
|
403 * missing, just call it to indicate it is ON (radio always on). |
|
404 * |
|
405 * Whenever the driver detects a change in the state of the RF kill |
|
406 * switches, it should call wimax_report_rfkill_hw() or |
|
407 * wimax_report_rfkill_sw() to report it to the stack. |
|
408 */ |
|
409 struct wimax_dev { |
|
410 struct net_device *net_dev; |
|
411 struct list_head id_table_node; |
|
412 struct mutex mutex; /* Protects all members and API calls */ |
|
413 struct mutex mutex_reset; |
|
414 enum wimax_st state; |
|
415 |
|
416 int (*op_msg_from_user)(struct wimax_dev *wimax_dev, |
|
417 const char *, |
|
418 const void *, size_t, |
|
419 const struct genl_info *info); |
|
420 int (*op_rfkill_sw_toggle)(struct wimax_dev *wimax_dev, |
|
421 enum wimax_rf_state); |
|
422 int (*op_reset)(struct wimax_dev *wimax_dev); |
|
423 |
|
424 struct rfkill *rfkill; |
|
425 struct input_dev *rfkill_input; |
|
426 unsigned rf_hw; |
|
427 unsigned rf_sw; |
|
428 char name[32]; |
|
429 |
|
430 struct dentry *debugfs_dentry; |
|
431 }; |
|
432 |
|
433 |
|
434 |
|
435 /* |
|
436 * WiMAX stack public API for device drivers |
|
437 * ----------------------------------------- |
|
438 * |
|
439 * These functions are not exported to user space. |
|
440 */ |
|
441 extern void wimax_dev_init(struct wimax_dev *); |
|
442 extern int wimax_dev_add(struct wimax_dev *, struct net_device *); |
|
443 extern void wimax_dev_rm(struct wimax_dev *); |
|
444 |
|
445 static inline |
|
446 struct wimax_dev *net_dev_to_wimax(struct net_device *net_dev) |
|
447 { |
|
448 return netdev_priv(net_dev); |
|
449 } |
|
450 |
|
451 static inline |
|
452 struct device *wimax_dev_to_dev(struct wimax_dev *wimax_dev) |
|
453 { |
|
454 return wimax_dev->net_dev->dev.parent; |
|
455 } |
|
456 |
|
457 extern void wimax_state_change(struct wimax_dev *, enum wimax_st); |
|
458 extern enum wimax_st wimax_state_get(struct wimax_dev *); |
|
459 |
|
460 /* |
|
461 * Radio Switch state reporting. |
|
462 * |
|
463 * enum wimax_rf_state is declared in linux/wimax.h so the exports |
|
464 * to user space can use it. |
|
465 */ |
|
466 extern void wimax_report_rfkill_hw(struct wimax_dev *, enum wimax_rf_state); |
|
467 extern void wimax_report_rfkill_sw(struct wimax_dev *, enum wimax_rf_state); |
|
468 |
|
469 |
|
470 /* |
|
471 * Free-form messaging to/from user space |
|
472 * |
|
473 * Sending a message: |
|
474 * |
|
475 * wimax_msg(wimax_dev, pipe_name, buf, buf_size, GFP_KERNEL); |
|
476 * |
|
477 * Broken up: |
|
478 * |
|
479 * skb = wimax_msg_alloc(wimax_dev, pipe_name, buf_size, GFP_KERNEL); |
|
480 * ...fill up skb... |
|
481 * wimax_msg_send(wimax_dev, pipe_name, skb); |
|
482 * |
|
483 * Be sure not to modify skb->data in the middle (ie: don't use |
|
484 * skb_push()/skb_pull()/skb_reserve() on the skb). |
|
485 * |
|
486 * "pipe_name" is any string, than can be interpreted as the name of |
|
487 * the pipe or destinatary; the interpretation of it is driver |
|
488 * specific, so the recipient can multiplex it as wished. It can be |
|
489 * NULL, it won't be used - an example is using a "diagnostics" tag to |
|
490 * send diagnostics information that a device-specific diagnostics |
|
491 * tool would be interested in. |
|
492 */ |
|
493 extern struct sk_buff *wimax_msg_alloc(struct wimax_dev *, const char *, |
|
494 const void *, size_t, gfp_t); |
|
495 extern int wimax_msg_send(struct wimax_dev *, struct sk_buff *); |
|
496 extern int wimax_msg(struct wimax_dev *, const char *, |
|
497 const void *, size_t, gfp_t); |
|
498 |
|
499 extern const void *wimax_msg_data_len(struct sk_buff *, size_t *); |
|
500 extern const void *wimax_msg_data(struct sk_buff *); |
|
501 extern ssize_t wimax_msg_len(struct sk_buff *); |
|
502 |
|
503 |
|
504 /* |
|
505 * WiMAX stack user space API |
|
506 * -------------------------- |
|
507 * |
|
508 * This API is what gets exported to user space for general |
|
509 * operations. As well, they can be called from within the kernel, |
|
510 * (with a properly referenced `struct wimax_dev`). |
|
511 * |
|
512 * Properly referenced means: the 'struct net_device' that embeds the |
|
513 * device's control structure and (as such) the 'struct wimax_dev' is |
|
514 * referenced by the caller. |
|
515 */ |
|
516 extern int wimax_rfkill(struct wimax_dev *, enum wimax_rf_state); |
|
517 extern int wimax_reset(struct wimax_dev *); |
|
518 |
|
519 #else |
|
520 /* You might be looking for linux/wimax.h */ |
|
521 #error This file should not be included from user space. |
|
522 #endif /* #ifdef __KERNEL__ */ |
|
523 #endif /* #ifndef __NET__WIMAX_H__ */ |