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