| Inaky Perez-Gonzalez | ace22f0 | 2008-12-20 16:57:33 -0800 | [diff] [blame] | 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 |  * | 
| André Goddard Rosa | af901ca | 2009-11-14 13:09:05 -0200 | [diff] [blame] | 82 |  * All API operations are 'atomic', serialized through a mutex in the | 
| Inaky Perez-Gonzalez | ace22f0 | 2008-12-20 16:57:33 -0800 | [diff] [blame] | 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 |  * | 
| Inaky Perez-Gonzalez | c2315b4 | 2009-09-16 17:10:55 -0700 | [diff] [blame] | 198 |  * The op_*() function pointers will not be called if the wimax_dev is | 
 | 199 |  * in a state <= %WIMAX_ST_UNINITIALIZED. The exception is: | 
 | 200 |  * | 
 | 201 |  * - op_reset: can be called at any time after wimax_dev_add() has | 
 | 202 |  *   been called. | 
 | 203 |  * | 
| Inaky Perez-Gonzalez | ace22f0 | 2008-12-20 16:57:33 -0800 | [diff] [blame] | 204 |  * THE PIPE INTERFACE: | 
 | 205 |  * | 
 | 206 |  * This interface is kept intentionally simple. The driver can send | 
 | 207 |  * and receive free-form messages to/from user space through a | 
 | 208 |  * pipe. See drivers/net/wimax/op-msg.c for details. | 
 | 209 |  * | 
 | 210 |  * The kernel-to-user messages are sent with | 
 | 211 |  * wimax_msg(). user-to-kernel messages are delivered via | 
 | 212 |  * wimax_dev->op_msg_from_user(). | 
 | 213 |  * | 
 | 214 |  * RFKILL: | 
 | 215 |  * | 
 | 216 |  * RFKILL support is built into the wimax_dev layer; the driver just | 
 | 217 |  * needs to call wimax_report_rfkill_{hw,sw}() to inform of changes in | 
 | 218 |  * the hardware or software RF kill switches. When the stack wants to | 
 | 219 |  * turn the radio off, it will call wimax_dev->op_rfkill_sw_toggle(), | 
 | 220 |  * which the driver implements. | 
 | 221 |  * | 
 | 222 |  * User space can set the software RF Kill switch by calling | 
 | 223 |  * wimax_rfkill(). | 
 | 224 |  * | 
 | 225 |  * The code for now only supports devices that don't require polling; | 
 | 226 |  * If the device needs to be polled, create a self-rearming delayed | 
 | 227 |  * work struct for polling or look into adding polled support to the | 
 | 228 |  * WiMAX stack. | 
 | 229 |  * | 
 | 230 |  * When initializing the hardware (_probe), after calling | 
 | 231 |  * wimax_dev_add(), query the device for it's RF Kill switches status | 
 | 232 |  * and feed it back to the WiMAX stack using | 
 | 233 |  * wimax_report_rfkill_{hw,sw}(). If any switch is missing, always | 
 | 234 |  * report it as ON. | 
 | 235 |  * | 
 | 236 |  * NOTE: the wimax stack uses an inverted terminology to that of the | 
 | 237 |  * RFKILL subsystem: | 
 | 238 |  * | 
 | 239 |  *  - ON: radio is ON, RFKILL is DISABLED or OFF. | 
 | 240 |  *  - OFF: radio is OFF, RFKILL is ENABLED or ON. | 
 | 241 |  * | 
 | 242 |  * MISCELLANEOUS OPS: | 
 | 243 |  * | 
 | 244 |  * wimax_reset() can be used to reset the device to power on state; by | 
 | 245 |  * default it issues a warm reset that maintains the same device | 
 | 246 |  * node. If that is not possible, it falls back to a cold reset | 
 | 247 |  * (device reconnect). The driver implements the backend to this | 
 | 248 |  * through wimax_dev->op_reset(). | 
 | 249 |  */ | 
 | 250 |  | 
 | 251 | #ifndef __NET__WIMAX_H__ | 
 | 252 | #define __NET__WIMAX_H__ | 
 | 253 | #ifdef __KERNEL__ | 
 | 254 |  | 
 | 255 | #include <linux/wimax.h> | 
 | 256 | #include <net/genetlink.h> | 
 | 257 | #include <linux/netdevice.h> | 
 | 258 |  | 
 | 259 | struct net_device; | 
 | 260 | struct genl_info; | 
 | 261 | struct wimax_dev; | 
| Inaky Perez-Gonzalez | ace22f0 | 2008-12-20 16:57:33 -0800 | [diff] [blame] | 262 |  | 
 | 263 | /** | 
 | 264 |  * struct wimax_dev - Generic WiMAX device | 
 | 265 |  * | 
 | 266 |  * @net_dev: [fill] Pointer to the &struct net_device this WiMAX | 
 | 267 |  *     device implements. | 
 | 268 |  * | 
 | 269 |  * @op_msg_from_user: [fill] Driver-specific operation to | 
 | 270 |  *     handle a raw message from user space to the driver. The | 
 | 271 |  *     driver can send messages to user space using with | 
 | 272 |  *     wimax_msg_to_user(). | 
 | 273 |  * | 
 | 274 |  * @op_rfkill_sw_toggle: [fill] Driver-specific operation to act on | 
 | 275 |  *     userspace (or any other agent) requesting the WiMAX device to | 
 | 276 |  *     change the RF Kill software switch (WIMAX_RF_ON or | 
 | 277 |  *     WIMAX_RF_OFF). | 
 | 278 |  *     If such hardware support is not present, it is assumed the | 
 | 279 |  *     radio cannot be switched off and it is always on (and the stack | 
 | 280 |  *     will error out when trying to switch it off). In such case, | 
 | 281 |  *     this function pointer can be left as NULL. | 
 | 282 |  * | 
 | 283 |  * @op_reset: [fill] Driver specific operation to reset the | 
 | 284 |  *     device. | 
 | 285 |  *     This operation should always attempt first a warm reset that | 
 | 286 |  *     does not disconnect the device from the bus and return 0. | 
 | 287 |  *     If that fails, it should resort to some sort of cold or bus | 
 | 288 |  *     reset (even if it implies a bus disconnection and device | 
 | 289 |  *     dissapearance). In that case, -ENODEV should be returned to | 
 | 290 |  *     indicate the device is gone. | 
 | 291 |  *     This operation has to be synchronous, and return only when the | 
 | 292 |  *     reset is complete. In case of having had to resort to bus/cold | 
 | 293 |  *     reset implying a device disconnection, the call is allowed to | 
 | 294 |  *     return inmediately. | 
 | 295 |  *     NOTE: wimax_dev->mutex is NOT locked when this op is being | 
 | 296 |  *     called; however, wimax_dev->mutex_reset IS locked to ensure | 
 | 297 |  *     serialization of calls to wimax_reset(). | 
 | 298 |  *     See wimax_reset()'s documentation. | 
 | 299 |  * | 
 | 300 |  * @name: [fill] A way to identify this device. We need to register a | 
| Johannes Berg | 19d337d | 2009-06-02 13:01:37 +0200 | [diff] [blame] | 301 |  *     name with many subsystems (rfkill, workqueue creation, etc). | 
 | 302 |  *     We can't use the network device name as that | 
| Inaky Perez-Gonzalez | ace22f0 | 2008-12-20 16:57:33 -0800 | [diff] [blame] | 303 |  *     might change and in some instances we don't know it yet (until | 
 | 304 |  *     we don't call register_netdev()). So we generate an unique one | 
 | 305 |  *     using the driver name and device bus id, place it here and use | 
 | 306 |  *     it across the board. Recommended naming: | 
 | 307 |  *     DRIVERNAME-BUSNAME:BUSID (dev->bus->name, dev->bus_id). | 
 | 308 |  * | 
 | 309 |  * @id_table_node: [private] link to the list of wimax devices kept by | 
 | 310 |  *     id-table.c. Protected by it's own spinlock. | 
 | 311 |  * | 
 | 312 |  * @mutex: [private] Serializes all concurrent access and execution of | 
 | 313 |  *     operations. | 
 | 314 |  * | 
 | 315 |  * @mutex_reset: [private] Serializes reset operations. Needs to be a | 
 | 316 |  *     different mutex because as part of the reset operation, the | 
 | 317 |  *     driver has to call back into the stack to do things such as | 
 | 318 |  *     state change, that require wimax_dev->mutex. | 
 | 319 |  * | 
 | 320 |  * @state: [private] Current state of the WiMAX device. | 
 | 321 |  * | 
 | 322 |  * @rfkill: [private] integration into the RF-Kill infrastructure. | 
 | 323 |  * | 
| Inaky Perez-Gonzalez | ace22f0 | 2008-12-20 16:57:33 -0800 | [diff] [blame] | 324 |  * @rf_sw: [private] State of the software radio switch (OFF/ON) | 
 | 325 |  * | 
 | 326 |  * @rf_hw: [private] State of the hardware radio switch (OFF/ON) | 
 | 327 |  * | 
| Inaky Perez-Gonzalez | 2a4d71d | 2009-01-09 07:34:00 +0000 | [diff] [blame] | 328 |  * @debugfs_dentry: [private] Used to hook up a debugfs entry. This | 
 | 329 |  *     shows up in the debugfs root as wimax\:DEVICENAME. | 
| Inaky Perez-Gonzalez | 56cf391 | 2009-01-08 12:56:57 -0800 | [diff] [blame] | 330 |  * | 
| Inaky Perez-Gonzalez | ace22f0 | 2008-12-20 16:57:33 -0800 | [diff] [blame] | 331 |  * Description: | 
 | 332 |  * This structure defines a common interface to access all WiMAX | 
 | 333 |  * devices from different vendors and provides a common API as well as | 
 | 334 |  * a free-form device-specific messaging channel. | 
 | 335 |  * | 
 | 336 |  * Usage: | 
 | 337 |  *  1. Embed a &struct wimax_dev at *the beginning* the network | 
 | 338 |  *     device structure so that netdev_priv() points to it. | 
 | 339 |  * | 
 | 340 |  *  2. memset() it to zero | 
 | 341 |  * | 
 | 342 |  *  3. Initialize with wimax_dev_init(). This will leave the WiMAX | 
 | 343 |  *     device in the %__WIMAX_ST_NULL state. | 
 | 344 |  * | 
 | 345 |  *  4. Fill all the fields marked with [fill]; once called | 
 | 346 |  *     wimax_dev_add(), those fields CANNOT be modified. | 
 | 347 |  * | 
 | 348 |  *  5. Call wimax_dev_add() *after* registering the network | 
 | 349 |  *     device. This will leave the WiMAX device in the %WIMAX_ST_DOWN | 
 | 350 |  *     state. | 
 | 351 |  *     Protect the driver's net_device->open() against succeeding if | 
 | 352 |  *     the wimax device state is lower than %WIMAX_ST_DOWN. | 
 | 353 |  * | 
 | 354 |  *  6. Select when the device is going to be turned on/initialized; | 
 | 355 |  *     for example, it could be initialized on 'ifconfig up' (when the | 
 | 356 |  *     netdev op 'open()' is called on the driver). | 
 | 357 |  * | 
 | 358 |  * When the device is initialized (at `ifconfig up` time, or right | 
 | 359 |  * after calling wimax_dev_add() from _probe(), make sure the | 
 | 360 |  * following steps are taken | 
 | 361 |  * | 
 | 362 |  *  a. Move the device to %WIMAX_ST_UNINITIALIZED. This is needed so | 
 | 363 |  *     some API calls that shouldn't work until the device is ready | 
 | 364 |  *     can be blocked. | 
 | 365 |  * | 
 | 366 |  *  b. Initialize the device. Make sure to turn the SW radio switch | 
 | 367 |  *     off and move the device to state %WIMAX_ST_RADIO_OFF when | 
 | 368 |  *     done. When just initialized, a device should be left in RADIO | 
 | 369 |  *     OFF state until user space devices to turn it on. | 
 | 370 |  * | 
 | 371 |  *  c. Query the device for the state of the hardware rfkill switch | 
 | 372 |  *     and call wimax_rfkill_report_hw() and wimax_rfkill_report_sw() | 
 | 373 |  *     as needed. See below. | 
 | 374 |  * | 
 | 375 |  * wimax_dev_rm() undoes before unregistering the network device. Once | 
 | 376 |  * wimax_dev_add() is called, the driver can get called on the | 
 | 377 |  * wimax_dev->op_* function pointers | 
 | 378 |  * | 
 | 379 |  * CONCURRENCY: | 
 | 380 |  * | 
 | 381 |  * The stack provides a mutex for each device that will disallow API | 
 | 382 |  * calls happening concurrently; thus, op calls into the driver | 
 | 383 |  * through the wimax_dev->op*() function pointers will always be | 
 | 384 |  * serialized and *never* concurrent. | 
 | 385 |  * | 
 | 386 |  * For locking, take wimax_dev->mutex is taken; (most) operations in | 
 | 387 |  * the API have to check for wimax_dev_is_ready() to return 0 before | 
 | 388 |  * continuing (this is done internally). | 
 | 389 |  * | 
 | 390 |  * REFERENCE COUNTING: | 
 | 391 |  * | 
 | 392 |  * The WiMAX device is reference counted by the associated network | 
 | 393 |  * device. The only operation that can be used to reference the device | 
 | 394 |  * is wimax_dev_get_by_genl_info(), and the reference it acquires has | 
 | 395 |  * to be released with dev_put(wimax_dev->net_dev). | 
 | 396 |  * | 
 | 397 |  * RFKILL: | 
 | 398 |  * | 
 | 399 |  * At startup, both HW and SW radio switchess are assumed to be off. | 
 | 400 |  * | 
 | 401 |  * At initialization time [after calling wimax_dev_add()], have the | 
 | 402 |  * driver query the device for the status of the software and hardware | 
 | 403 |  * RF kill switches and call wimax_report_rfkill_hw() and | 
 | 404 |  * wimax_rfkill_report_sw() to indicate their state. If any is | 
 | 405 |  * missing, just call it to indicate it is ON (radio always on). | 
 | 406 |  * | 
 | 407 |  * Whenever the driver detects a change in the state of the RF kill | 
 | 408 |  * switches, it should call wimax_report_rfkill_hw() or | 
 | 409 |  * wimax_report_rfkill_sw() to report it to the stack. | 
 | 410 |  */ | 
 | 411 | struct wimax_dev { | 
 | 412 | 	struct net_device *net_dev; | 
 | 413 | 	struct list_head id_table_node; | 
 | 414 | 	struct mutex mutex;		/* Protects all members and API calls */ | 
 | 415 | 	struct mutex mutex_reset; | 
 | 416 | 	enum wimax_st state; | 
 | 417 |  | 
 | 418 | 	int (*op_msg_from_user)(struct wimax_dev *wimax_dev, | 
 | 419 | 				const char *, | 
 | 420 | 				const void *, size_t, | 
 | 421 | 				const struct genl_info *info); | 
 | 422 | 	int (*op_rfkill_sw_toggle)(struct wimax_dev *wimax_dev, | 
 | 423 | 				   enum wimax_rf_state); | 
 | 424 | 	int (*op_reset)(struct wimax_dev *wimax_dev); | 
 | 425 |  | 
 | 426 | 	struct rfkill *rfkill; | 
 | 427 | 	struct input_dev *rfkill_input; | 
 | 428 | 	unsigned rf_hw; | 
 | 429 | 	unsigned rf_sw; | 
 | 430 | 	char name[32]; | 
 | 431 |  | 
 | 432 | 	struct dentry *debugfs_dentry; | 
 | 433 | }; | 
 | 434 |  | 
 | 435 |  | 
 | 436 |  | 
 | 437 | /* | 
 | 438 |  * WiMAX stack public API for device drivers | 
 | 439 |  * ----------------------------------------- | 
 | 440 |  * | 
 | 441 |  * These functions are not exported to user space. | 
 | 442 |  */ | 
 | 443 | extern void wimax_dev_init(struct wimax_dev *); | 
 | 444 | extern int wimax_dev_add(struct wimax_dev *, struct net_device *); | 
 | 445 | extern void wimax_dev_rm(struct wimax_dev *); | 
 | 446 |  | 
 | 447 | static inline | 
 | 448 | struct wimax_dev *net_dev_to_wimax(struct net_device *net_dev) | 
 | 449 | { | 
 | 450 | 	return netdev_priv(net_dev); | 
 | 451 | } | 
 | 452 |  | 
 | 453 | static inline | 
 | 454 | struct device *wimax_dev_to_dev(struct wimax_dev *wimax_dev) | 
 | 455 | { | 
 | 456 | 	return wimax_dev->net_dev->dev.parent; | 
 | 457 | } | 
 | 458 |  | 
 | 459 | extern void wimax_state_change(struct wimax_dev *, enum wimax_st); | 
 | 460 | extern enum wimax_st wimax_state_get(struct wimax_dev *); | 
 | 461 |  | 
 | 462 | /* | 
 | 463 |  * Radio Switch state reporting. | 
 | 464 |  * | 
 | 465 |  * enum wimax_rf_state is declared in linux/wimax.h so the exports | 
 | 466 |  * to user space can use it. | 
 | 467 |  */ | 
 | 468 | extern void wimax_report_rfkill_hw(struct wimax_dev *, enum wimax_rf_state); | 
 | 469 | extern void wimax_report_rfkill_sw(struct wimax_dev *, enum wimax_rf_state); | 
 | 470 |  | 
 | 471 |  | 
 | 472 | /* | 
 | 473 |  * Free-form messaging to/from user space | 
 | 474 |  * | 
 | 475 |  * Sending a message: | 
 | 476 |  * | 
 | 477 |  *   wimax_msg(wimax_dev, pipe_name, buf, buf_size, GFP_KERNEL); | 
 | 478 |  * | 
 | 479 |  * Broken up: | 
 | 480 |  * | 
 | 481 |  *   skb = wimax_msg_alloc(wimax_dev, pipe_name, buf_size, GFP_KERNEL); | 
 | 482 |  *   ...fill up skb... | 
 | 483 |  *   wimax_msg_send(wimax_dev, pipe_name, skb); | 
 | 484 |  * | 
 | 485 |  * Be sure not to modify skb->data in the middle (ie: don't use | 
 | 486 |  * skb_push()/skb_pull()/skb_reserve() on the skb). | 
 | 487 |  * | 
 | 488 |  * "pipe_name" is any string, than can be interpreted as the name of | 
 | 489 |  * the pipe or destinatary; the interpretation of it is driver | 
 | 490 |  * specific, so the recipient can multiplex it as wished. It can be | 
 | 491 |  * NULL, it won't be used - an example is using a "diagnostics" tag to | 
 | 492 |  * send diagnostics information that a device-specific diagnostics | 
 | 493 |  * tool would be interested in. | 
 | 494 |  */ | 
 | 495 | extern struct sk_buff *wimax_msg_alloc(struct wimax_dev *, const char *, | 
 | 496 | 				       const void *, size_t, gfp_t); | 
 | 497 | extern int wimax_msg_send(struct wimax_dev *, struct sk_buff *); | 
 | 498 | extern int wimax_msg(struct wimax_dev *, const char *, | 
 | 499 | 		     const void *, size_t, gfp_t); | 
 | 500 |  | 
 | 501 | extern const void *wimax_msg_data_len(struct sk_buff *, size_t *); | 
 | 502 | extern const void *wimax_msg_data(struct sk_buff *); | 
 | 503 | extern ssize_t wimax_msg_len(struct sk_buff *); | 
 | 504 |  | 
 | 505 |  | 
 | 506 | /* | 
 | 507 |  * WiMAX stack user space API | 
 | 508 |  * -------------------------- | 
 | 509 |  * | 
 | 510 |  * This API is what gets exported to user space for general | 
 | 511 |  * operations. As well, they can be called from within the kernel, | 
 | 512 |  * (with a properly referenced `struct wimax_dev`). | 
 | 513 |  * | 
 | 514 |  * Properly referenced means: the 'struct net_device' that embeds the | 
 | 515 |  * device's control structure and (as such) the 'struct wimax_dev' is | 
 | 516 |  * referenced by the caller. | 
 | 517 |  */ | 
 | 518 | extern int wimax_rfkill(struct wimax_dev *, enum wimax_rf_state); | 
 | 519 | extern int wimax_reset(struct wimax_dev *); | 
 | 520 |  | 
 | 521 | #else | 
 | 522 | /* You might be looking for linux/wimax.h */ | 
 | 523 | #error This file should not be included from user space. | 
 | 524 | #endif /* #ifdef __KERNEL__ */ | 
 | 525 | #endif /* #ifndef __NET__WIMAX_H__ */ |