^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) /* SPDX-License-Identifier: GPL-2.0 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) * This file define the new driver API for Wireless Extensions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) * Version : 8 16.3.07
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) * Authors : Jean Tourrilhes - HPL - <jt@hpl.hp.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) * Copyright (c) 2001-2007 Jean Tourrilhes, All Rights Reserved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) #ifndef _IW_HANDLER_H
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) #define _IW_HANDLER_H
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) /************************** DOCUMENTATION **************************/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) * Initial driver API (1996 -> onward) :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) * -----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) * The initial API just sends the IOCTL request received from user space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) * to the driver (via the driver ioctl handler). The driver has to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) * handle all the rest...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) * The initial API also defines a specific handler in struct net_device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) * to handle wireless statistics.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) * The initial APIs served us well and has proven a reasonably good design.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) * However, there is a few shortcommings :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) * o No events, everything is a request to the driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) * o Large ioctl function in driver with gigantic switch statement
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) * (i.e. spaghetti code).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) * o Driver has to mess up with copy_to/from_user, and in many cases
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) * does it unproperly. Common mistakes are :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) * * buffer overflows (no checks or off by one checks)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) * * call copy_to/from_user with irq disabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) * o The user space interface is tied to ioctl because of the use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) * copy_to/from_user.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) * New driver API (2002 -> onward) :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) * -------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) * The new driver API is just a bunch of standard functions (handlers),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) * each handling a specific Wireless Extension. The driver just export
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) * the list of handler it supports, and those will be called apropriately.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) * I tried to keep the main advantage of the previous API (simplicity,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) * efficiency and light weight), and also I provide a good dose of backward
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) * compatibility (most structures are the same, driver can use both API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) * simultaneously, ...).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) * Hopefully, I've also addressed the shortcomming of the initial API.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) * The advantage of the new API are :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) * o Handling of Extensions in driver broken in small contained functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) * o Tighter checks of ioctl before calling the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) * o Flexible commit strategy (at least, the start of it)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) * o Backward compatibility (can be mixed with old API)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) * o Driver doesn't have to worry about memory and user-space issues
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) * The last point is important for the following reasons :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) * o You are now able to call the new driver API from any API you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) * want (including from within other parts of the kernel).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) * o Common mistakes are avoided (buffer overflow, user space copy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) * with irq disabled and so on).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) * The Drawback of the new API are :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) * o bloat (especially kernel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) * o need to migrate existing drivers to new API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) * My initial testing shows that the new API adds around 3kB to the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) * and save between 0 and 5kB from a typical driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) * Also, as all structures and data types are unchanged, the migration is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) * quite straightforward (but tedious).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) * ---
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) * The new driver API is defined below in this file. User space should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) * not be aware of what's happening down there...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) * A new kernel wrapper is in charge of validating the IOCTLs and calling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) * the appropriate driver handler. This is implemented in :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) * # net/core/wireless.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) * The driver export the list of handlers in :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) * # include/linux/netdevice.h (one place)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) * The new driver API is available for WIRELESS_EXT >= 13.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) * Good luck with migration to the new API ;-)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) /* ---------------------- THE IMPLEMENTATION ---------------------- */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) * Some of the choice I've made are pretty controversials. Defining an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) * API is very much weighting compromises. This goes into some of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) * details and the thinking behind the implementation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) * Implementation goals :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) * --------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) * The implementation goals were as follow :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) * o Obvious : you should not need a PhD to understand what's happening,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) * the benefit is easier maintenance.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) * o Flexible : it should accommodate a wide variety of driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) * implementations and be as flexible as the old API.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) * o Lean : it should be efficient memory wise to minimise the impact
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) * on kernel footprint.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) * o Transparent to user space : the large number of user space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) * applications that use Wireless Extensions should not need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) * any modifications.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) * Array of functions versus Struct of functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) * ---------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) * 1) Having an array of functions allow the kernel code to access the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) * handler in a single lookup, which is much more efficient (think hash
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) * table here).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) * 2) The only drawback is that driver writer may put their handler in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) * the wrong slot. This is trivial to test (I set the frequency, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) * bitrate changes). Once the handler is in the proper slot, it will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) * there forever, because the array is only extended at the end.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) * 3) Backward/forward compatibility : adding new handler just require
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) * extending the array, so you can put newer driver in older kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) * without having to patch the kernel code (and vice versa).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) * All handler are of the same generic type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) * ----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) * That's a feature !!!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) * 1) Having a generic handler allow to have generic code, which is more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) * efficient. If each of the handler was individually typed I would need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) * to add a big switch in the kernel (== more bloat). This solution is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) * more scalable, adding new Wireless Extensions doesn't add new code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) * 2) You can use the same handler in different slots of the array. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) * hardware, it may be more efficient or logical to handle multiple
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) * Wireless Extensions with a single function, and the API allow you to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) * do that. (An example would be a single record on the card to control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) * both bitrate and frequency, the handler would read the old record,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) * modify it according to info->cmd and rewrite it).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) * Functions prototype uses union iwreq_data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) * -----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) * Some would have preferred functions defined this way :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) * static int mydriver_ioctl_setrate(struct net_device *dev,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) * long rate, int auto)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) * 1) The kernel code doesn't "validate" the content of iwreq_data, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) * can't do it (different hardware may have different notion of what a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) * valid frequency is), so we don't pretend that we do it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) * 2) The above form is not extendable. If I want to add a flag (for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) * example to distinguish setting max rate and basic rate), I would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) * break the prototype. Using iwreq_data is more flexible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) * 3) Also, the above form is not generic (see above).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) * 4) I don't expect driver developper using the wrong field of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) * union (Doh !), so static typechecking doesn't add much value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) * 5) Lastly, you can skip the union by doing :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) * static int mydriver_ioctl_setrate(struct net_device *dev,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) * struct iw_request_info *info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) * struct iw_param *rrq,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) * char *extra)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) * And then adding the handler in the array like this :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) * (iw_handler) mydriver_ioctl_setrate, // SIOCSIWRATE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) * Using functions and not a registry
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) * ----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) * Another implementation option would have been for every instance to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) * define a registry (a struct containing all the Wireless Extensions)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) * and only have a function to commit the registry to the hardware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) * 1) This approach can be emulated by the current code, but not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) * vice versa.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) * 2) Some drivers don't keep any configuration in the driver, for them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) * adding such a registry would be a significant bloat.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) * 3) The code to translate from Wireless Extension to native format is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) * needed anyway, so it would not reduce significantely the amount of code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) * 4) The current approach only selectively translate Wireless Extensions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) * to native format and only selectively set, whereas the registry approach
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) * would require to translate all WE and set all parameters for any single
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) * change.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) * 5) For many Wireless Extensions, the GET operation return the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) * dynamic value, not the value that was set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) * This header is <net/iw_handler.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) * ---------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) * 1) This header is kernel space only and should not be exported to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) * user space. Headers in "include/linux/" are exported, headers in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) * "include/net/" are not.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) * Mixed 32/64 bit issues
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) * ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) * The Wireless Extensions are designed to be 64 bit clean, by using only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) * datatypes with explicit storage size.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) * There are some issues related to kernel and user space using different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) * memory model, and in particular 64bit kernel with 32bit user space.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) * The problem is related to struct iw_point, that contains a pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) * that *may* need to be translated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) * This is quite messy. The new API doesn't solve this problem (it can't),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) * but is a step in the right direction :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) * 1) Meta data about each ioctl is easily available, so we know what type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) * of translation is needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) * 2) The move of data between kernel and user space is only done in a single
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) * place in the kernel, so adding specific hooks in there is possible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) * 3) In the long term, it allows to move away from using ioctl as the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) * user space API.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) * So many comments and so few code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) * --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) * That's a feature. Comments won't bloat the resulting kernel binary.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) /***************************** INCLUDES *****************************/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) #include <linux/wireless.h> /* IOCTL user space API */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) #include <linux/if_ether.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) /***************************** VERSION *****************************/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) * This constant is used to know which version of the driver API is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) * available. Hopefully, this will be pretty stable and no changes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) * will be needed...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) * I just plan to increment with each new version.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) #define IW_HANDLER_VERSION 8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) * Changes :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) * V2 to V3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) * --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) * - Move event definition in <linux/wireless.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) * - Add Wireless Event support :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) * o wireless_send_event() prototype
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) * o iwe_stream_add_event/point() inline functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) * V3 to V4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) * --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) * - Reshuffle IW_HEADER_TYPE_XXX to map IW_PRIV_TYPE_XXX changes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) * V4 to V5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) * --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) * - Add new spy support : struct iw_spy_data & prototypes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) * V5 to V6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) * --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) * - Change the way we get to spy_data method for added safety
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) * - Remove spy #ifdef, they are always on -> cleaner code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) * - Add IW_DESCR_FLAG_NOMAX flag for very large requests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) * - Start migrating get_wireless_stats to struct iw_handler_def
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) * V6 to V7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) * --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) * - Add struct ieee80211_device pointer in struct iw_public_data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) * - Remove (struct iw_point *)->pointer from events and streams
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) * - Remove spy_offset from struct iw_handler_def
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) * - Add "check" version of event macros for ieee802.11 stack
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) * V7 to V8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) * ----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) * - Prevent leaking of kernel space in stream on 64 bits.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) /**************************** CONSTANTS ****************************/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) /* Enhanced spy support available */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) #define IW_WIRELESS_SPY
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) #define IW_WIRELESS_THRSPY
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) /* Special error message for the driver to indicate that we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) * should do a commit after return from the iw_handler */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) #define EIWCOMMIT EINPROGRESS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) /* Flags available in struct iw_request_info */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) #define IW_REQUEST_FLAG_COMPAT 0x0001 /* Compat ioctl call */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) /* Type of headers we know about (basically union iwreq_data) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) #define IW_HEADER_TYPE_NULL 0 /* Not available */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) #define IW_HEADER_TYPE_CHAR 2 /* char [IFNAMSIZ] */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) #define IW_HEADER_TYPE_UINT 4 /* __u32 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) #define IW_HEADER_TYPE_FREQ 5 /* struct iw_freq */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) #define IW_HEADER_TYPE_ADDR 6 /* struct sockaddr */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) #define IW_HEADER_TYPE_POINT 8 /* struct iw_point */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) #define IW_HEADER_TYPE_PARAM 9 /* struct iw_param */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) #define IW_HEADER_TYPE_QUAL 10 /* struct iw_quality */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) /* Handling flags */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) /* Most are not implemented. I just use them as a reminder of some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) * cool features we might need one day ;-) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) #define IW_DESCR_FLAG_NONE 0x0000 /* Obvious */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) /* Wrapper level flags */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) #define IW_DESCR_FLAG_DUMP 0x0001 /* Not part of the dump command */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) #define IW_DESCR_FLAG_EVENT 0x0002 /* Generate an event on SET */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) #define IW_DESCR_FLAG_RESTRICT 0x0004 /* GET : request is ROOT only */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) /* SET : Omit payload from generated iwevent */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) #define IW_DESCR_FLAG_NOMAX 0x0008 /* GET : no limit on request size */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) /* Driver level flags */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) #define IW_DESCR_FLAG_WAIT 0x0100 /* Wait for driver event */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) /****************************** TYPES ******************************/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) /* ----------------------- WIRELESS HANDLER ----------------------- */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) * A wireless handler is just a standard function, that looks like the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) * ioctl handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) * We also define there how a handler list look like... As the Wireless
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) * Extension space is quite dense, we use a simple array, which is faster
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) * (that's the perfect hash table ;-).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) * Meta data about the request passed to the iw_handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) * Most handlers can safely ignore what's in there.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) * The 'cmd' field might come handy if you want to use the same handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) * for multiple command...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) * This struct is also my long term insurance. I can add new fields here
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) * without breaking the prototype of iw_handler...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) struct iw_request_info {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) __u16 cmd; /* Wireless Extension command */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) __u16 flags; /* More to come ;-) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) struct net_device;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) * This is how a function handling a Wireless Extension should look
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) * like (both get and set, standard and private).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) typedef int (*iw_handler)(struct net_device *dev, struct iw_request_info *info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) union iwreq_data *wrqu, char *extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) * This define all the handler that the driver export.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) * As you need only one per driver type, please use a static const
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) * shared by all driver instances... Same for the members...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) * This will be linked from net_device in <linux/netdevice.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) struct iw_handler_def {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) /* Array of handlers for standard ioctls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) * We will call dev->wireless_handlers->standard[ioctl - SIOCIWFIRST]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) const iw_handler * standard;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) /* Number of handlers defined (more precisely, index of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) * last defined handler + 1) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) __u16 num_standard;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) #ifdef CONFIG_WEXT_PRIV
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) __u16 num_private;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) /* Number of private arg description */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) __u16 num_private_args;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) /* Array of handlers for private ioctls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) * Will call dev->wireless_handlers->private[ioctl - SIOCIWFIRSTPRIV]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) const iw_handler * private;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) /* Arguments of private handler. This one is just a list, so you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) * can put it in any order you want and should not leave holes...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) * We will automatically export that to user space... */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) const struct iw_priv_args * private_args;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) /* New location of get_wireless_stats, to de-bloat struct net_device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) * The old pointer in struct net_device will be gradually phased
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) * out, and drivers are encouraged to use this one... */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) struct iw_statistics* (*get_wireless_stats)(struct net_device *dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) /* ---------------------- IOCTL DESCRIPTION ---------------------- */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) * One of the main goal of the new interface is to deal entirely with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) * user space/kernel space memory move.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) * For that, we need to know :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) * o if iwreq is a pointer or contain the full data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) * o what is the size of the data to copy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) * For private IOCTLs, we use the same rules as used by iwpriv and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) * defined in struct iw_priv_args.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) * For standard IOCTLs, things are quite different and we need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) * use the structures below. Actually, this struct is also more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) * efficient, but that's another story...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) * Describe how a standard IOCTL looks like.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) struct iw_ioctl_description {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) __u8 header_type; /* NULL, iw_point or other */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) __u8 token_type; /* Future */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) __u16 token_size; /* Granularity of payload */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) __u16 min_tokens; /* Min acceptable token number */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) __u16 max_tokens; /* Max acceptable token number */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) __u32 flags; /* Special handling of the request */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) /* Need to think of short header translation table. Later. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) /* --------------------- ENHANCED SPY SUPPORT --------------------- */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) * In the old days, the driver was handling spy support all by itself.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) * Now, the driver can delegate this task to Wireless Extensions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) * It needs to include this struct in its private part and use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) * standard spy iw_handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) * Instance specific spy data, i.e. addresses spied and quality for them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) struct iw_spy_data {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) /* --- Standard spy support --- */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) int spy_number;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) u_char spy_address[IW_MAX_SPY][ETH_ALEN];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) struct iw_quality spy_stat[IW_MAX_SPY];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) /* --- Enhanced spy support (event) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) struct iw_quality spy_thr_low; /* Low threshold */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) struct iw_quality spy_thr_high; /* High threshold */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) u_char spy_thr_under[IW_MAX_SPY];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) /* --------------------- DEVICE WIRELESS DATA --------------------- */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) * This is all the wireless data specific to a device instance that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) * is managed by the core of Wireless Extensions or the 802.11 layer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) * We only keep pointer to those structures, so that a driver is free
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) * to share them between instances.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) * This structure should be initialised before registering the device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) * Access to this data follow the same rules as any other struct net_device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) * data (i.e. valid as long as struct net_device exist, same locking rules).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) /* Forward declaration */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) struct libipw_device;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) /* The struct */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) struct iw_public_data {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) /* Driver enhanced spy support */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) struct iw_spy_data * spy_data;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) /* Legacy structure managed by the ipw2x00-specific IEEE 802.11 layer */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) struct libipw_device * libipw;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) /**************************** PROTOTYPES ****************************/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) * Functions part of the Wireless Extensions (defined in net/core/wireless.c).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) * Those may be called only within the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) /* First : function strictly used inside the kernel */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) /* Handle /proc/net/wireless, called in net/code/dev.c */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) int dev_get_wireless_info(char *buffer, char **start, off_t offset, int length);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) /* Second : functions that may be called by driver modules */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) /* Send a single event to user space */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) void wireless_send_event(struct net_device *dev, unsigned int cmd,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) union iwreq_data *wrqu, const char *extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443) #ifdef CONFIG_WEXT_CORE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) /* flush all previous wext events - if work is done from netdev notifiers */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) void wireless_nlevent_flush(void);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) #else
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) static inline void wireless_nlevent_flush(void) {}
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) /* We may need a function to send a stream of events to user space.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) * More on that later... */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) /* Standard handler for SIOCSIWSPY */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) int iw_handler_set_spy(struct net_device *dev, struct iw_request_info *info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) union iwreq_data *wrqu, char *extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) /* Standard handler for SIOCGIWSPY */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) int iw_handler_get_spy(struct net_device *dev, struct iw_request_info *info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) union iwreq_data *wrqu, char *extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) /* Standard handler for SIOCSIWTHRSPY */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) int iw_handler_set_thrspy(struct net_device *dev, struct iw_request_info *info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) union iwreq_data *wrqu, char *extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) /* Standard handler for SIOCGIWTHRSPY */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) int iw_handler_get_thrspy(struct net_device *dev, struct iw_request_info *info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) union iwreq_data *wrqu, char *extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) /* Driver call to update spy records */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) void wireless_spy_update(struct net_device *dev, unsigned char *address,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) struct iw_quality *wstats);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) /************************* INLINE FUNTIONS *************************/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) * Function that are so simple that it's more efficient inlining them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) static inline int iwe_stream_lcp_len(struct iw_request_info *info)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) #ifdef CONFIG_COMPAT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) if (info->flags & IW_REQUEST_FLAG_COMPAT)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) return IW_EV_COMPAT_LCP_LEN;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) return IW_EV_LCP_LEN;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) static inline int iwe_stream_point_len(struct iw_request_info *info)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) #ifdef CONFIG_COMPAT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) if (info->flags & IW_REQUEST_FLAG_COMPAT)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) return IW_EV_COMPAT_POINT_LEN;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) return IW_EV_POINT_LEN;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) static inline int iwe_stream_event_len_adjust(struct iw_request_info *info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) int event_len)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) #ifdef CONFIG_COMPAT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) if (info->flags & IW_REQUEST_FLAG_COMPAT) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) event_len -= IW_EV_LCP_LEN;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) event_len += IW_EV_COMPAT_LCP_LEN;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) return event_len;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) /*------------------------------------------------------------------*/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) * Wrapper to add an Wireless Event to a stream of events.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) char *iwe_stream_add_event(struct iw_request_info *info, char *stream,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) char *ends, struct iw_event *iwe, int event_len);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) static inline char *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) iwe_stream_add_event_check(struct iw_request_info *info, char *stream,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) char *ends, struct iw_event *iwe, int event_len)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516) char *res = iwe_stream_add_event(info, stream, ends, iwe, event_len);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) if (res == stream)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) return ERR_PTR(-E2BIG);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) return res;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) /*------------------------------------------------------------------*/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) * Wrapper to add an short Wireless Event containing a pointer to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) * stream of events.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) char *iwe_stream_add_point(struct iw_request_info *info, char *stream,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) char *ends, struct iw_event *iwe, char *extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) static inline char *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) iwe_stream_add_point_check(struct iw_request_info *info, char *stream,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) char *ends, struct iw_event *iwe, char *extra)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) char *res = iwe_stream_add_point(info, stream, ends, iwe, extra);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) if (res == stream)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) return ERR_PTR(-E2BIG);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) return res;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) /*------------------------------------------------------------------*/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) * Wrapper to add a value to a Wireless Event in a stream of events.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) * Be careful, this one is tricky to use properly :
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) * At the first run, you need to have (value = event + IW_EV_LCP_LEN).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) char *iwe_stream_add_value(struct iw_request_info *info, char *event,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) char *value, char *ends, struct iw_event *iwe,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) int event_len);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) #endif /* _IW_HANDLER_H */