/*
* Linux WiMAX
* Kernel space API for accessing WiMAX devices
*
*
* Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
* Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License version
* 2 as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301, USA.
*
*
* The WiMAX stack provides an API for controlling and managing the
* system's WiMAX devices. This API affects the control plane; the
* data plane is accessed via the network stack (netdev).
*
* Parts of the WiMAX stack API and notifications are exported to
* user space via Generic Netlink. In user space, libwimax (part of
* the wimax-tools package) provides a shim layer for accessing those
* calls.
*
* The API is standarized for all WiMAX devices and different drivers
* implement the backend support for it. However, device-specific
* messaging pipes are provided that can be used to issue commands and
* receive notifications in free form.
*
* Currently the messaging pipes are the only means of control as it
* is not known (due to the lack of more devices in the market) what
* will be a good abstraction layer. Expect this to change as more
* devices show in the market. This API is designed to be growable in
* order to address this problem.
*
* USAGE
*
* Embed a `struct wimax_dev` at the beginning of the the device's
* private structure, initialize and register it. For details, see
* `struct wimax_dev`s documentation.
*
* Once this is done, wimax-tools's libwimaxll can be used to
* communicate with the driver from user space. You user space
* application does not have to forcibily use libwimaxll and can talk
* the generic netlink protocol directly if desired.
*
* Remember this is a very low level API that will to provide all of
* WiMAX features. Other daemons and services running in user space
* are the expected clients of it. They offer a higher level API that
* applications should use (an example of this is the Intel's WiMAX
* Network Service for the i2400m).
*
* DESIGN
*
* Although not set on final stone, this very basic interface is
* mostly completed. Remember this is meant to grow as new common
* operations are decided upon. New operations will be added to the
* interface, intent being on keeping backwards compatibility as much
* as possible.
*
* This layer implements a set of calls to control a WiMAX device,
* exposing a frontend to the rest of the kernel and user space (via
* generic netlink) and a backend implementation in the driver through
* function pointers.
*
* WiMAX devices have a state, and a kernel-only API allows the
* drivers to manipulate that state. State transitions are atomic, and
* only some of them are allowed (see `enum wimax_st`).
*
* Most API calls will set the state automatically; in most cases
* drivers have to only report state changes due to external
* conditions.
*
* All API operations are 'atomic', serialized through a mutex in the
* `struct wimax_dev`.
*
* EXPORTING TO USER SPACE THROUGH GENERIC NETLINK
*
* The API is exported to user space using generic netlink (other
* methods can be added as needed).
*
* There is a Generic Netlink Family named "WiMAX", where interfaces
* supporting the WiMAX interface receive commands and broadcast their
* signals over a multicast group named "msg".
*
* Mapping to the source/destination interface is done by an interface
* index attribute.
*
* For user-to-kernel traffic (commands) we use a function call
* marshalling mechanism, where a message X with attributes A, B, C
* sent from user space to kernel space means executing the WiMAX API
* call wimax_X(A, B, C), sending the results back as a message.
*
* Kernel-to-user (notifications or signals) communication is sent
* over multicast groups. This allows to have multiple applications
* monitoring them.
*
* Each command/signal gets assigned it's own attribute policy. This