Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

3 Commits   0 Branches   0 Tags
^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 */