openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
linux/drivers/net/wireless/rt2x00/rt2x00lib.h

461 lines
14 KiB
C
Raw Normal View History

[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
/*
rt2x00: Update copyright statements. As mentioned on the linux-wireless mailing list, the current copyright statements in the rt2x00 are meaningless, as the rt2x00 project is not even a formal legal entity. Therefore it is better to replace the existing copyright statements with copyright statements for the people that actually wrote the code. Note: Updated to the best of my knowledge with respect to who contributed considerable amounts of code. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> CC: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-08 23:39:55 +08:00
Copyright (C) 2004 - 2009 Ivo van Doorn <IvDoorn@gmail.com>
Copyright (C) 2004 - 2009 Gertjan van Wingerde <gwingerde@gmail.com>
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
<http://rt2x00.serialmonkey.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
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.,
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
/*
Module: rt2x00lib
Abstract: Data structures and definitions for the rt2x00lib module.
*/
#ifndef RT2X00LIB_H
#define RT2X00LIB_H
rt2x00: trim skb_frame_desc to 32 bytes Remove frame_type from skb_frame_desc and pass it as argument to rt2x00debug_dump_frame(). Change data_len and desc_len to unsigned short to save another 4 bytes in skb_frame_desc. Note that this was the only location where the data_len and desc_len was not yet treated as unsigned short. This trim is required to help mac80211 with adding the TX control and TX status informtation into the skb->cb structure. When that happens, drivers will have approximately 40 bytes left to use freely. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-10 19:41:32 +08:00
#include "rt2x00dump.h"
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
/*
* Interval defines
*/
rt2x00: Style fix for interval defines Extra parenthesis are not needed in these 2 cases, all other defines in rt2x00 are done without parenthesis so just fixup these 2 cases. Signed-off-by: Alban Browaeys <prahal@yahoo.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-30 04:00:23 +08:00
#define LINK_TUNE_INTERVAL round_jiffies_relative(HZ)
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
rt2x00: Rate structure overhaul Recent changes to the rate structure registration broke rt2x00, the hw_value was reduced from 32bits to 16bits while rt2x00 used the full 32bits. However the way rt2x00 used the value was inflexible and needed to be changed anyway. This patch creates a array containing information for each rate, the hw_value passed to mac80211 is the index value for that array including a field to indicate if short preamble should be enabled. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-03 22:50:40 +08:00
/*
* rt2x00_rate: Per rate device information
*/
struct rt2x00_rate {
unsigned short flags;
rt2x00: Cleanup mode registration Don't wildly pass any number for num_rates to rt2x00lib, instead pass which type of rates are supported (CCK, OFDM). Same for num_modes but then for the 2GHZ and 5GHZ band. This makes the interface look much nicer and makes extending it later easier. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-18 00:35:05 +08:00
#define DEV_RATE_CCK 0x0001
#define DEV_RATE_OFDM 0x0002
#define DEV_RATE_SHORT_PREAMBLE 0x0004
rt2x00: Rate structure overhaul Recent changes to the rate structure registration broke rt2x00, the hw_value was reduced from 32bits to 16bits while rt2x00 used the full 32bits. However the way rt2x00 used the value was inflexible and needed to be changed anyway. This patch creates a array containing information for each rate, the hw_value passed to mac80211 is the index value for that array including a field to indicate if short preamble should be enabled. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-03 22:50:40 +08:00
unsigned short bitrate; /* In 100kbit/s */
unsigned short ratemask;
unsigned short plcp;
rt2x00: Implement support for 802.11n Extend rt2x00lib capabilities to support 802.11n, it still lacks aggregation support, but that can be added in the future. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:09:32 +08:00
unsigned short mcs;
rt2x00: Rate structure overhaul Recent changes to the rate structure registration broke rt2x00, the hw_value was reduced from 32bits to 16bits while rt2x00 used the full 32bits. However the way rt2x00 used the value was inflexible and needed to be changed anyway. This patch creates a array containing information for each rate, the hw_value passed to mac80211 is the index value for that array including a field to indicate if short preamble should be enabled. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-03 22:50:40 +08:00
};
extern const struct rt2x00_rate rt2x00_supported_rates[12];
static inline const struct rt2x00_rate *rt2x00_get_rate(const u16 hw_value)
{
return &rt2x00_supported_rates[hw_value & 0xff];
}
rt2x00: Implement support for 802.11n Extend rt2x00lib capabilities to support 802.11n, it still lacks aggregation support, but that can be added in the future. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:09:32 +08:00
#define RATE_MCS(__mode, __mcs) \
( (((__mode) & 0x00ff) << 8) | ((__mcs) & 0x00ff) )
static inline int rt2x00_get_rate_mcs(const u16 mcs_value)
{
return (mcs_value & 0x00ff);
}
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
/*
* Radio control handlers.
*/
int rt2x00lib_enable_radio(struct rt2x00_dev *rt2x00dev);
void rt2x00lib_disable_radio(struct rt2x00_dev *rt2x00dev);
[PATCH] rt2x00: Pass dev_state to rt2x00lib_toggle_rx Directly pass a value from the enum dev_state with rt2x00lib_toggle_rx, this will save us a ? : statement, and it is clearer then passing a 1 0 argument. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-10-06 20:16:09 +08:00
void rt2x00lib_toggle_rx(struct rt2x00_dev *rt2x00dev, enum dev_state state);
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
/*
* Initialization handlers.
*/
rt2x00: Move start() and stop() handlers into rt2x00lib.c suspend & resume was broken since it called rt2x00mac_start() and rt2x00mac_stop() which would fail to execute because the DEVICE_PRESENT flag was not set. Move the start and stop handlers into rt2x00lib.c which are called from rt2x00mac_start() and rt2x00mac_stop() after they have checked the DEVICE_PRESENT flag, while suspend and resume handlers can directly call those functions. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-01-07 06:40:07 +08:00
int rt2x00lib_start(struct rt2x00_dev *rt2x00dev);
void rt2x00lib_stop(struct rt2x00_dev *rt2x00dev);
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
/*
* Configuration handlers.
*/
rt2x00: Add per-interface structure Rework the interface handling. Delete the interface structure and replace it with a per-interface structure. This changes the way rt2x00 handles the active interface drastically. Copy ieee80211_bss_conf to the this rt2x00_intf structure during the bss_info_changed() callback function. This will allow us to reference it later, and removes the requirement for the device flag SHORT_PREAMBLE flag which is interface specific. Drivers receive the option to give the maximum number of virtual interfaces the device can handle. Virtual interface support: rt2400pci: 1 sta or 1 ap, * monitor interfaces rt2500pci: 1 sta or 1 ap, * monitor interfaces rt2500usb: 1 sta or 1 ap, * monitor interfaces rt61pci: 1 sta or 4 ap, * monitor interfaces rt73usb: 1 sta or 4 ap, * monitor interfaces At the moment none of the drivers support AP and STA interfaces simultaneously, this is a hardware limitation so future support will be very unlikely. Each interface structure receives its dedicated beacon entry, with this we can easily work with beaconing while multiple master mode interfaces are currently active. The configuration handlers for the MAC, BSSID and type are often called together since they all belong to the interface configuration. Merge the 3 configuration calls and cleanup the API between rt2x00lib and the drivers. While we are cleaning up the interface configuration anyway, we might as well clean up the configuration handler as well. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-03 22:49:59 +08:00
void rt2x00lib_config_intf(struct rt2x00_dev *rt2x00dev,
struct rt2x00_intf *intf,
mac80211: use nl80211 interface types There's really no reason for mac80211 to be using its own interface type defines. Use the nl80211 types and simplify the configuration code a bit: there's no need to translate them any more now. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-11 06:01:58 +08:00
enum nl80211_iftype type,
mac80211: constify ieee80211_if_conf.bssid Then one place can be a static const. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-01-21 19:47:05 +08:00
const u8 *mac, const u8 *bssid);
rt2x00: Rename config_preamble() to config_erp() Rename config_preamble() to config_erp() and cleanup argument list by putting it all into a single structure. This will make the function more meaningful and easier to expand later. This second option is mostly intended to make the patch "mac80211: proper short-slot handling" from Johannes Berg easier to apply for rt2x00. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-10 05:46:18 +08:00
void rt2x00lib_config_erp(struct rt2x00_dev *rt2x00dev,
struct rt2x00_intf *intf,
struct ieee80211_bss_conf *conf);
[PATCH] rt2x00: Implement SW diversity When mac80211 indicates that the default antenna setup should be used _and_ that this default setup is SW_DIVERSITY. This requires sampling and storing the RSSI per antenna and check once every 2 seconds to determine if the RSSI has changed significantly. Once this is the case we should sample the other antenna for a short period and evaluate if we need to swap antenna or not. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-13 22:26:36 +08:00
void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
rt2x00: Don't alter rt2x00dev->default_ant rt2x00dev->default_ant should be initialized once by the driver, and should not be changed afterwards. Because rt2x00lib_config_antenna() was using a reference to the struct antenna_setup it actually had the oppurtunity to change the default antenna setting and it actually did that during the validation. Instead of passing a pointer to antenna_setup the entire structure should be copied. Signed-off-by: Lars Ericsson <Lars_Ericsson@telia.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-19 02:21:52 +08:00
struct antenna_setup ant);
[PATCH] rt2x00: Reorganize rt2x00dev->flags The rt2x00dev->flags has become a chaos over time, this will reorganize the flags by renaming, deleting, adding and properly implement the flags. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-09-26 02:55:39 +08:00
void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
rt2x00: Optimize configuration handling Implement latest changed from mac80211 configuration handling to optmize configuration handling in rt2x00. * Remove set_retry_limit callback function, handled through config() * Move config_antenna to its own callback function, it isn't handled by mac80211 anymore * Use IEEE80211_CONF_CHANGED_* flags and remove manual checks * Removed deprecated short slot setting through config() and put it in config_erp() through which mac80211 now configures it * Remove config_phymode() and move contents to config_erp() since it only managed the basic rates which is now determined by mac80211 through config_erp(). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-30 00:17:57 +08:00
struct ieee80211_conf *conf,
const unsigned int changed_flags);
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
rt2x00: Cleanup symbol exports With a bit of code moving to rt2x00lib within the TX and RX paths we can now remove a lot of EXPORT_SYMBOL_GPL() statements. This cleans up the interface between rt2x00lib and the drivers and has the additional benefit that rt2x00pci and rt2x00usb are trimmed down in size as well since they have less to do. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-06-17 01:56:54 +08:00
/**
* DOC: Queue handlers
*/
/**
* rt2x00queue_alloc_rxskb - allocate a skb for RX purposes.
* @rt2x00dev: Pointer to &struct rt2x00_dev.
* @queue: The queue for which the skb will be applicable.
*/
struct sk_buff *rt2x00queue_alloc_rxskb(struct rt2x00_dev *rt2x00dev,
struct queue_entry *entry);
/**
* rt2x00queue_unmap_skb - Unmap a skb from DMA.
* @rt2x00dev: Pointer to &struct rt2x00_dev.
* @skb: The skb to unmap.
*/
void rt2x00queue_unmap_skb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb);
/**
* rt2x00queue_free_skb - free a skb
* @rt2x00dev: Pointer to &struct rt2x00_dev.
* @skb: The skb to free.
*/
void rt2x00queue_free_skb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb);
rt2x00: Add support for L2 padding during TX/RX Some hardware require L2 padding between header and payload because both must be aligned to a 4-byte boundary. This hardware also is easier during the RX path since we no longer need to move the entire payload but rather only the header to remove the padding (mac80211 only wants the payload to be 4-byte aligned). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:50 +08:00
/**
rt2x00: Reorganize padding & L2 padding The old function rt2x00queue_payload_align() handled both adding and removing L2 padding and some basic frame alignment. The entire function was being abused because it had multiple functions and the header length argument was somtimes used to align the header instead of the payload. Additionally there was a bug when inserting L2 padding that only the payload was aligned but not the header. This happens when the header wasn't aligned properly by mac80211, but rt2x00lib only moves the payload. A secondary problem was that when removing L2 padding during TXdone or RX the skb wasn't resized to the proper size. Split the function into seperate functions each handling its task as it should. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-08-30 02:30:45 +08:00
* rt2x00queue_align_frame - Align 802.11 frame to 4-byte boundary
* @skb: The skb to align
*
* Align the start of the 802.11 frame to a 4-byte boundary, this could
* mean the payload is not aligned properly though.
*/
void rt2x00queue_align_frame(struct sk_buff *skb);
/**
* rt2x00queue_align_payload - Align 802.11 payload to 4-byte boundary
* @skb: The skb to align
* @header_length: Length of 802.11 header
*
* Align the 802.11 payload to a 4-byte boundary, this could
* mean the header is not aligned properly though.
*/
void rt2x00queue_align_payload(struct sk_buff *skb, unsigned int header_length);
/**
* rt2x00queue_insert_l2pad - Align 802.11 header & payload to 4-byte boundary
* @skb: The skb to align
* @header_length: Length of 802.11 header
*
* Apply L2 padding to align both header and payload to 4-byte boundary
*/
void rt2x00queue_insert_l2pad(struct sk_buff *skb, unsigned int header_length);
/**
* rt2x00queue_insert_l2pad - Remove L2 padding from 802.11 frame
rt2x00: Add support for L2 padding during TX/RX Some hardware require L2 padding between header and payload because both must be aligned to a 4-byte boundary. This hardware also is easier during the RX path since we no longer need to move the entire payload but rather only the header to remove the padding (mac80211 only wants the payload to be 4-byte aligned). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:50 +08:00
* @skb: The skb to align
* @header_length: Length of 802.11 header
*
rt2x00: Reorganize padding & L2 padding The old function rt2x00queue_payload_align() handled both adding and removing L2 padding and some basic frame alignment. The entire function was being abused because it had multiple functions and the header length argument was somtimes used to align the header instead of the payload. Additionally there was a bug when inserting L2 padding that only the payload was aligned but not the header. This happens when the header wasn't aligned properly by mac80211, but rt2x00lib only moves the payload. A secondary problem was that when removing L2 padding during TXdone or RX the skb wasn't resized to the proper size. Split the function into seperate functions each handling its task as it should. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-08-30 02:30:45 +08:00
* Remove L2 padding used to align both header and payload to 4-byte boundary,
* by removing the L2 padding the header will no longer be 4-byte aligned.
rt2x00: Add support for L2 padding during TX/RX Some hardware require L2 padding between header and payload because both must be aligned to a 4-byte boundary. This hardware also is easier during the RX path since we no longer need to move the entire payload but rather only the header to remove the padding (mac80211 only wants the payload to be 4-byte aligned). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:50 +08:00
*/
rt2x00: Reorganize padding & L2 padding The old function rt2x00queue_payload_align() handled both adding and removing L2 padding and some basic frame alignment. The entire function was being abused because it had multiple functions and the header length argument was somtimes used to align the header instead of the payload. Additionally there was a bug when inserting L2 padding that only the payload was aligned but not the header. This happens when the header wasn't aligned properly by mac80211, but rt2x00lib only moves the payload. A secondary problem was that when removing L2 padding during TXdone or RX the skb wasn't resized to the proper size. Split the function into seperate functions each handling its task as it should. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-08-30 02:30:45 +08:00
void rt2x00queue_remove_l2pad(struct sk_buff *skb, unsigned int header_length);
rt2x00: Add support for L2 padding during TX/RX Some hardware require L2 padding between header and payload because both must be aligned to a 4-byte boundary. This hardware also is easier during the RX path since we no longer need to move the entire payload but rather only the header to remove the padding (mac80211 only wants the payload to be 4-byte aligned). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:50 +08:00
rt2x00: Cleanup symbol exports With a bit of code moving to rt2x00lib within the TX and RX paths we can now remove a lot of EXPORT_SYMBOL_GPL() statements. This cleans up the interface between rt2x00lib and the drivers and has the additional benefit that rt2x00pci and rt2x00usb are trimmed down in size as well since they have less to do. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-06-17 01:56:54 +08:00
/**
* rt2x00queue_write_tx_frame - Write TX frame to hardware
* @queue: Queue over which the frame should be send
* @skb: The skb to send
mac80211: request TX status where needed Right now all frames mac80211 hands to the driver have the IEEE80211_TX_CTL_REQ_TX_STATUS flag set to request TX status. This isn't really necessary, only the injected frames need TX status (the latter for hostapd) so move setting this flag. The rate control algorithms also need TX status, but they don't require it. Also, rt2x00 uses that bit for its own purposes and seems to require it being set for all frames, but that can be fixed in rt2x00. This doesn't really change anything for any drivers but in the future drivers using hw-rate control may opt to not report TX status for frames that don't have the IEEE80211_TX_CTL_REQ_TX_STATUS flag set. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> [rt2x00 bits] Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-19 08:08:30 +08:00
* @local: frame is not from mac80211
rt2x00: Queue handling overhaul This introduces a big queue handling overhaul, this also renames "ring" to "queues". Move queue handling into rt2x00queue.c and the matching header, use Kerneldoc to improve rt2x00 library documentation. Access to the queues is now protected under a spinlock, this to prevent race conditions which could corrupt the indexing system of the queue. Each queue entry allocates x bytes for driver/device specific data, this cleans up the queue structure significantly and improves code readability. rt2500usb no longer needs 2 entries in the beacon queue to correctly send out the guardian byte. This is now handled in the entry specific structure. rt61 and rt73 now use the correct descriptor size for beacon frames, since this data is written into the registers not the entire TXD descriptor was used but instead of a subset of it named TXINFO. Finally this also fixes numerous other bugs related to incorrect beacon handling or beacon related code. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-06 05:42:23 +08:00
*/
mac80211: request TX status where needed Right now all frames mac80211 hands to the driver have the IEEE80211_TX_CTL_REQ_TX_STATUS flag set to request TX status. This isn't really necessary, only the injected frames need TX status (the latter for hostapd) so move setting this flag. The rate control algorithms also need TX status, but they don't require it. Also, rt2x00 uses that bit for its own purposes and seems to require it being set for all frames, but that can be fixed in rt2x00. This doesn't really change anything for any drivers but in the future drivers using hw-rate control may opt to not report TX status for frames that don't have the IEEE80211_TX_CTL_REQ_TX_STATUS flag set. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> [rt2x00 bits] Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-19 08:08:30 +08:00
int rt2x00queue_write_tx_frame(struct data_queue *queue, struct sk_buff *skb,
bool local);
rt2x00: Cleanup symbol exports With a bit of code moving to rt2x00lib within the TX and RX paths we can now remove a lot of EXPORT_SYMBOL_GPL() statements. This cleans up the interface between rt2x00lib and the drivers and has the additional benefit that rt2x00pci and rt2x00usb are trimmed down in size as well since they have less to do. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-06-17 01:56:54 +08:00
rt2x00: Reorganize beacon handling With the new beacon handling from mac80211 we can reorganize the beacon handling in rt2x00 as well. This patch will move the function to the TX handlers, and move all duplicate code into rt2x00queue.c. After this change the descriptor helper functions from rt2x00queue.c no longer need to be exported outside of rt2x00lib and can be declared static. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 21:12:44 +08:00
/**
* rt2x00queue_update_beacon - Send new beacon from mac80211 to hardware
* @rt2x00dev: Pointer to &struct rt2x00_dev.
* @vif: Interface for which the beacon should be updated.
rt2x00: Add kill_tx_queue callback function provide rt2x00lib the possibility to kill a particular TX queue. This can be useful when disabling the radio, but more importantly will allow beaconing to be disabled when mac80211 requests this (during scanning for example) Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-01-28 07:32:33 +08:00
* @enable_beacon: Enable beaconing
rt2x00: Reorganize beacon handling With the new beacon handling from mac80211 we can reorganize the beacon handling in rt2x00 as well. This patch will move the function to the TX handlers, and move all duplicate code into rt2x00queue.c. After this change the descriptor helper functions from rt2x00queue.c no longer need to be exported outside of rt2x00lib and can be declared static. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 21:12:44 +08:00
*/
int rt2x00queue_update_beacon(struct rt2x00_dev *rt2x00dev,
rt2x00: Add kill_tx_queue callback function provide rt2x00lib the possibility to kill a particular TX queue. This can be useful when disabling the radio, but more importantly will allow beaconing to be disabled when mac80211 requests this (during scanning for example) Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-01-28 07:32:33 +08:00
struct ieee80211_vif *vif,
const bool enable_beacon);
rt2x00: Reorganize beacon handling With the new beacon handling from mac80211 we can reorganize the beacon handling in rt2x00 as well. This patch will move the function to the TX handlers, and move all duplicate code into rt2x00queue.c. After this change the descriptor helper functions from rt2x00queue.c no longer need to be exported outside of rt2x00lib and can be declared static. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 21:12:44 +08:00
rt2x00: Cleanup symbol exports With a bit of code moving to rt2x00lib within the TX and RX paths we can now remove a lot of EXPORT_SYMBOL_GPL() statements. This cleans up the interface between rt2x00lib and the drivers and has the additional benefit that rt2x00pci and rt2x00usb are trimmed down in size as well since they have less to do. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-06-17 01:56:54 +08:00
/**
* rt2x00queue_index_inc - Index incrementation function
* @queue: Queue (&struct data_queue) to perform the action on.
* @index: Index type (&enum queue_index) to perform the action on.
*
* This function will increase the requested index on the queue,
* it will grab the appropriate locks and handle queue overflow events by
* resetting the index to the start of the queue.
*/
void rt2x00queue_index_inc(struct data_queue *queue, enum queue_index index);
rt2x00: Add kill_tx_queue callback function provide rt2x00lib the possibility to kill a particular TX queue. This can be useful when disabling the radio, but more importantly will allow beaconing to be disabled when mac80211 requests this (during scanning for example) Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-01-28 07:32:33 +08:00
/**
* rt2x00queue_stop_queues - Halt all data queues
* @rt2x00dev: Pointer to &struct rt2x00_dev.
*
* This function will loop through all available queues to stop
* any pending outgoing frames.
*/
void rt2x00queue_stop_queues(struct rt2x00_dev *rt2x00dev);
rt2x00: Cleanup TX/RX entry handling Merge the callback functions init_txentry() and init_rxentry(). This makes life in rt2x00lib a lot simpler and we can cleanup several functions. rt2x00pci contained "fake" FIELD definitions for descriptor words. This is not flexible since it assumes the driver will always have the same field to indicate if a driver is available or not. This should be dependent on the driver, and we should add a callback function for this. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-11-08 22:25:33 +08:00
/**
* rt2x00queue_init_queues - Initialize all data queues
* @rt2x00dev: Pointer to &struct rt2x00_dev.
*
* This function will loop through all available queues to clear all
* index numbers and set the queue entry to the correct initialization
* state.
*/
void rt2x00queue_init_queues(struct rt2x00_dev *rt2x00dev);
rt2x00: Queue handling overhaul This introduces a big queue handling overhaul, this also renames "ring" to "queues". Move queue handling into rt2x00queue.c and the matching header, use Kerneldoc to improve rt2x00 library documentation. Access to the queues is now protected under a spinlock, this to prevent race conditions which could corrupt the indexing system of the queue. Each queue entry allocates x bytes for driver/device specific data, this cleans up the queue structure significantly and improves code readability. rt2500usb no longer needs 2 entries in the beacon queue to correctly send out the guardian byte. This is now handled in the entry specific structure. rt61 and rt73 now use the correct descriptor size for beacon frames, since this data is written into the registers not the entire TXD descriptor was used but instead of a subset of it named TXINFO. Finally this also fixes numerous other bugs related to incorrect beacon handling or beacon related code. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-06 05:42:23 +08:00
int rt2x00queue_initialize(struct rt2x00_dev *rt2x00dev);
void rt2x00queue_uninitialize(struct rt2x00_dev *rt2x00dev);
int rt2x00queue_allocate(struct rt2x00_dev *rt2x00dev);
void rt2x00queue_free(struct rt2x00_dev *rt2x00dev);
rt2x00: Move link tuning into seperate file Move link and antenna tuning into a seperate file named rt2x00link.c, this makes the interface to the link tuner a lot cleaner. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-20 17:53:29 +08:00
/**
* rt2x00link_update_stats - Update link statistics from RX frame
* @rt2x00dev: Pointer to &struct rt2x00_dev.
* @skb: Received frame
* @rxdesc: Received frame descriptor
*
* Update link statistics based on the information from the
* received frame descriptor.
*/
void rt2x00link_update_stats(struct rt2x00_dev *rt2x00dev,
struct sk_buff *skb,
struct rxdone_entry_desc *rxdesc);
/**
* rt2x00link_start_tuner - Start periodic link tuner work
* @rt2x00dev: Pointer to &struct rt2x00_dev.
*
* This start the link tuner periodic work, this work will
* be executed periodically until &rt2x00link_stop_tuner has
* been called.
*/
void rt2x00link_start_tuner(struct rt2x00_dev *rt2x00dev);
/**
* rt2x00link_stop_tuner - Stop periodic link tuner work
* @rt2x00dev: Pointer to &struct rt2x00_dev.
*
* After this function completed the link tuner will not
* be running until &rt2x00link_start_tuner is called.
*/
void rt2x00link_stop_tuner(struct rt2x00_dev *rt2x00dev);
/**
* rt2x00link_reset_tuner - Reset periodic link tuner work
* @rt2x00dev: Pointer to &struct rt2x00_dev.
* @antenna: Should the antenna tuning also be reset
*
* The VGC limit configured in the hardware will be reset to 0
* which forces the driver to rediscover the correct value for
* the current association. This is needed when configuration
* options have changed which could drastically change the
* SNR level or link quality (i.e. changing the antenna setting).
*
* Resetting the link tuner will also cause the periodic work counter
* to be reset. Any driver which has a fixed limit on the number
* of rounds the link tuner is supposed to work will accept the
* tuner actions again if this limit was previously reached.
*
* If @antenna is set to true a the software antenna diversity
* tuning will also be reset.
*/
void rt2x00link_reset_tuner(struct rt2x00_dev *rt2x00dev, bool antenna);
/**
* rt2x00link_register - Initialize link tuning functionality
* @rt2x00dev: Pointer to &struct rt2x00_dev.
*
* Initialize work structure and all link tuning related
trivial: fix typos s/paramter/parameter/ and s/excute/execute/ in documentation and source comments. Signed-off-by: Martin Olsson <martin@minimum.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-04-23 00:21:29 +08:00
* parameters. This will not start the link tuning process itself.
rt2x00: Move link tuning into seperate file Move link and antenna tuning into a seperate file named rt2x00link.c, this makes the interface to the link tuner a lot cleaner. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-20 17:53:29 +08:00
*/
void rt2x00link_register(struct rt2x00_dev *rt2x00dev);
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
/*
* Firmware handlers.
*/
#ifdef CONFIG_RT2X00_LIB_FIRMWARE
int rt2x00lib_load_firmware(struct rt2x00_dev *rt2x00dev);
void rt2x00lib_free_firmware(struct rt2x00_dev *rt2x00dev);
#else
static inline int rt2x00lib_load_firmware(struct rt2x00_dev *rt2x00dev)
{
return 0;
}
static inline void rt2x00lib_free_firmware(struct rt2x00_dev *rt2x00dev)
{
}
#endif /* CONFIG_RT2X00_LIB_FIRMWARE */
/*
* Debugfs handlers.
*/
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
void rt2x00debug_register(struct rt2x00_dev *rt2x00dev);
void rt2x00debug_deregister(struct rt2x00_dev *rt2x00dev);
rt2x00: trim skb_frame_desc to 32 bytes Remove frame_type from skb_frame_desc and pass it as argument to rt2x00debug_dump_frame(). Change data_len and desc_len to unsigned short to save another 4 bytes in skb_frame_desc. Note that this was the only location where the data_len and desc_len was not yet treated as unsigned short. This trim is required to help mac80211 with adding the TX control and TX status informtation into the skb->cb structure. When that happens, drivers will have approximately 40 bytes left to use freely. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-10 19:41:32 +08:00
void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
enum rt2x00_dump_type type, struct sk_buff *skb);
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
void rt2x00debug_update_crypto(struct rt2x00_dev *rt2x00dev,
rt2x00: Move link tuning into seperate file Move link and antenna tuning into a seperate file named rt2x00link.c, this makes the interface to the link tuner a lot cleaner. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-20 17:53:29 +08:00
struct rxdone_entry_desc *rxdesc);
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
#else
static inline void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
{
}
static inline void rt2x00debug_deregister(struct rt2x00_dev *rt2x00dev)
{
}
rt2x00: Add TX/RX frame dumping facility This adds TX/RX frame dumping capabilities through debugfs. The intention is that with this approach debugging of rt2x00 is simplified since _all_ frames going in and out of the device are send to debugfs as well along with additional information like the hardware descriptor. Based on the patch by Mattias Nissler. Mattias also has some tools that will make the dumped frames available to wireshark: http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/ Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-11-28 04:49:29 +08:00
static inline void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
rt2x00: trim skb_frame_desc to 32 bytes Remove frame_type from skb_frame_desc and pass it as argument to rt2x00debug_dump_frame(). Change data_len and desc_len to unsigned short to save another 4 bytes in skb_frame_desc. Note that this was the only location where the data_len and desc_len was not yet treated as unsigned short. This trim is required to help mac80211 with adding the TX control and TX status informtation into the skb->cb structure. When that happens, drivers will have approximately 40 bytes left to use freely. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-10 19:41:32 +08:00
enum rt2x00_dump_type type,
rt2x00: correct "skb_buff" typo Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-12-05 06:24:35 +08:00
struct sk_buff *skb)
rt2x00: Add TX/RX frame dumping facility This adds TX/RX frame dumping capabilities through debugfs. The intention is that with this approach debugging of rt2x00 is simplified since _all_ frames going in and out of the device are send to debugfs as well along with additional information like the hardware descriptor. Based on the patch by Mattias Nissler. Mattias also has some tools that will make the dumped frames available to wireshark: http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/ Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-11-28 04:49:29 +08:00
{
}
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
static inline void rt2x00debug_update_crypto(struct rt2x00_dev *rt2x00dev,
rt2x00: Move link tuning into seperate file Move link and antenna tuning into a seperate file named rt2x00link.c, this makes the interface to the link tuner a lot cleaner. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-20 17:53:29 +08:00
struct rxdone_entry_desc *rxdesc)
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
{
}
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
/*
* Crypto handlers.
*/
#ifdef CONFIG_RT2X00_LIB_CRYPTO
enum cipher rt2x00crypto_key_to_cipher(struct ieee80211_key_conf *key);
rt2x00: Move crypto TX descriptor handling to rt2x00crypto.c Move all code which determines the right TX descriptor fields specific to crypto support into rt2x00crypto.c. This makes the code in rt2x00queue more simpler and better concentrates all crypto code into a single location. With this we can also remove some ifdefs in rt2x00queue.c since the code inside the ifdef is either very small, or only calling empty functions (see empty function definitions in rt2x00lib.h). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-04 00:29:48 +08:00
void rt2x00crypto_create_tx_descriptor(struct queue_entry *entry,
struct txentry_desc *txdesc);
rt2x00: Move code into seperate functions Some functions have grown rapidly in size over the last time, some of those functions (like the rt2x00queue_create_tx_descriptor) will further increase in size soon, so it is best to start cutting it into logical pieces. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-20 17:58:33 +08:00
unsigned int rt2x00crypto_tx_overhead(struct rt2x00_dev *rt2x00dev,
struct sk_buff *skb);
rt2x00: Move iv_len into tx descriptor data By placing the iv_len into the tx descriptor data and by passing this data to the crypto IV handlers we can save multiple calls to ieee80211_get_hdrlen_from_skb() and some if-statements when copying/removing the IV data from the outgoing frame. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:30 +08:00
void rt2x00crypto_tx_copy_iv(struct sk_buff *skb,
struct txentry_desc *txdesc);
void rt2x00crypto_tx_remove_iv(struct sk_buff *skb,
struct txentry_desc *txdesc);
rt2x00: Add support for L2 padding during TX/RX Some hardware require L2 padding between header and payload because both must be aligned to a 4-byte boundary. This hardware also is easier during the RX path since we no longer need to move the entire payload but rather only the header to remove the padding (mac80211 only wants the payload to be 4-byte aligned). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:50 +08:00
void rt2x00crypto_tx_insert_iv(struct sk_buff *skb, unsigned int header_length);
rt2x00: Reorganize padding & L2 padding The old function rt2x00queue_payload_align() handled both adding and removing L2 padding and some basic frame alignment. The entire function was being abused because it had multiple functions and the header length argument was somtimes used to align the header instead of the payload. Additionally there was a bug when inserting L2 padding that only the payload was aligned but not the header. This happens when the header wasn't aligned properly by mac80211, but rt2x00lib only moves the payload. A secondary problem was that when removing L2 padding during TXdone or RX the skb wasn't resized to the proper size. Split the function into seperate functions each handling its task as it should. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-08-30 02:30:45 +08:00
void rt2x00crypto_rx_insert_iv(struct sk_buff *skb,
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
unsigned int header_length,
struct rxdone_entry_desc *rxdesc);
#else
static inline enum cipher rt2x00crypto_key_to_cipher(struct ieee80211_key_conf *key)
{
return CIPHER_NONE;
}
rt2x00: Move crypto TX descriptor handling to rt2x00crypto.c Move all code which determines the right TX descriptor fields specific to crypto support into rt2x00crypto.c. This makes the code in rt2x00queue more simpler and better concentrates all crypto code into a single location. With this we can also remove some ifdefs in rt2x00queue.c since the code inside the ifdef is either very small, or only calling empty functions (see empty function definitions in rt2x00lib.h). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-04 00:29:48 +08:00
static inline void rt2x00crypto_create_tx_descriptor(struct queue_entry *entry,
struct txentry_desc *txdesc)
{
}
rt2x00: Move code into seperate functions Some functions have grown rapidly in size over the last time, some of those functions (like the rt2x00queue_create_tx_descriptor) will further increase in size soon, so it is best to start cutting it into logical pieces. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-20 17:58:33 +08:00
static inline unsigned int rt2x00crypto_tx_overhead(struct rt2x00_dev *rt2x00dev,
struct sk_buff *skb)
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
{
return 0;
}
rt2x00: Implement HW encryption (rt2500usb) rt2500usb supports hardware encryption. rt2500usb supports up to 4 shared and pairwise keys. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-03 01:20:42 +08:00
static inline void rt2x00crypto_tx_copy_iv(struct sk_buff *skb,
rt2x00: Move iv_len into tx descriptor data By placing the iv_len into the tx descriptor data and by passing this data to the crypto IV handlers we can save multiple calls to ieee80211_get_hdrlen_from_skb() and some if-statements when copying/removing the IV data from the outgoing frame. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:30 +08:00
struct txentry_desc *txdesc)
rt2x00: Implement HW encryption (rt2500usb) rt2500usb supports hardware encryption. rt2500usb supports up to 4 shared and pairwise keys. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-03 01:20:42 +08:00
{
}
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
static inline void rt2x00crypto_tx_remove_iv(struct sk_buff *skb,
rt2x00: Move iv_len into tx descriptor data By placing the iv_len into the tx descriptor data and by passing this data to the crypto IV handlers we can save multiple calls to ieee80211_get_hdrlen_from_skb() and some if-statements when copying/removing the IV data from the outgoing frame. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:30 +08:00
struct txentry_desc *txdesc)
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
{
}
rt2x00: Add support for L2 padding during TX/RX Some hardware require L2 padding between header and payload because both must be aligned to a 4-byte boundary. This hardware also is easier during the RX path since we no longer need to move the entire payload but rather only the header to remove the padding (mac80211 only wants the payload to be 4-byte aligned). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:08:50 +08:00
static inline void rt2x00crypto_tx_insert_iv(struct sk_buff *skb,
unsigned int header_length)
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
{
}
rt2x00: fix the definition of rt2x00crypto_rx_insert_iv Remove the redundant l2pad parameter from the definition of rt2x00crypto_rx_insert_iv which is used when only CONFIG_RT2500PCI but none of the other rt2x00 family drivers is configured. Signed-off-by: Andrew Price <andy@andrewprice.me.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-09-18 04:15:48 +08:00
static inline void rt2x00crypto_rx_insert_iv(struct sk_buff *skb,
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
unsigned int header_length,
struct rxdone_entry_desc *rxdesc)
{
}
rt2x00: Move crypto TX descriptor handling to rt2x00crypto.c Move all code which determines the right TX descriptor fields specific to crypto support into rt2x00crypto.c. This makes the code in rt2x00queue more simpler and better concentrates all crypto code into a single location. With this we can also remove some ifdefs in rt2x00queue.c since the code inside the ifdef is either very small, or only calling empty functions (see empty function definitions in rt2x00lib.h). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-12-04 00:29:48 +08:00
#endif /* CONFIG_RT2X00_LIB_CRYPTO */
rt2x00: Implement HW encryption Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04 22:37:44 +08:00
rt2x00: Implement support for 802.11n Extend rt2x00lib capabilities to support 802.11n, it still lacks aggregation support, but that can be added in the future. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-26 22:09:32 +08:00
/*
* HT handlers.
*/
#ifdef CONFIG_RT2X00_LIB_HT
void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
struct txentry_desc *txdesc,
const struct rt2x00_rate *hwrate);
#else
static inline void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
struct txentry_desc *txdesc,
const struct rt2x00_rate *hwrate)
{
}
#endif /* CONFIG_RT2X00_LIB_HT */
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
/*
* RFkill handlers.
*/
rt2x00: Add suspend/resume handlers to rt2x00rfkill Add suspend/resume handlers to rt2x00rfkill to have it stop the input-polldev and prevent it from calling rt2x00 during suspend period. This could lead to a NULL pointer fault when rt2x00 suspended, but polldev send a request, because the csr_addr is NULL. Also don't let the rfkill allocation/registration block the initialization of the entire device. Just print a warning and continue as if nothing happened. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-13 22:38:03 +08:00
static inline void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
{
rt2x00: use wiphy rfkill interface Remove the input_polldev from rt2x00 and replace it with the rfkill interface offered by the wiphy structure. This simplifies the entire rfkill handling in rt2x00 and allows us to remove the CONFIG_RT2X00_LIB_RFKILL option and always enables rfkill capabilities. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-01 21:17:35 +08:00
if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags))
wiphy_rfkill_start_polling(rt2x00dev->hw->wiphy);
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
}
static inline void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
{
rt2x00: use wiphy rfkill interface Remove the input_polldev from rt2x00 and replace it with the rfkill interface offered by the wiphy structure. This simplifies the entire rfkill handling in rt2x00 and allows us to remove the CONFIG_RT2X00_LIB_RFKILL option and always enables rfkill capabilities. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-01 21:17:35 +08:00
if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags))
wiphy_rfkill_stop_polling(rt2x00dev->hw->wiphy);
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
}
rt2x00: Make use of MAC80211_LED_TRIGGERS Make use of the led triggers provided by mac80211 to control the led status. This can be enabled through a per-driver configuration option which will automatically enable the generic handler in rt2x00lib. This has been enabled for rt2500usb and rt73usb for the moment since the led class will call set_brightness in irq context which will not work correctly with the usb drivers who need to sleep. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-03 22:53:40 +08:00
/*
* LED handlers
*/
#ifdef CONFIG_RT2X00_LIB_LEDS
void rt2x00leds_led_quality(struct rt2x00_dev *rt2x00dev, int rssi);
rt2x00: Fix quality/activity led handling There was an obvious typo in LED structure initialization which caused the radio and quality/activity leds to be incorrectly initialized which resulted in the leds not being enabled. Additionally add the rt2x00led_led_activity() handler that will enable TX/RX activity leds when the radio is being enabled. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-04-22 01:01:09 +08:00
void rt2x00led_led_activity(struct rt2x00_dev *rt2x00dev, bool enabled);
rt2x00: Remove MAC80211_LEDS dependency Implement triggers inside rt2x00 itself based on input from mac80211. This replaces the method of using the mac80211 trigger events which do not work for USB drivers due to the scheduling requirement. After this patch RT2500USB_LEDS and RT73USB_LEDS no longer need to be tagged as broken since they now support LED handling again without having to check for in_atomic(). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-31 21:53:44 +08:00
void rt2x00leds_led_assoc(struct rt2x00_dev *rt2x00dev, bool enabled);
void rt2x00leds_led_radio(struct rt2x00_dev *rt2x00dev, bool enabled);
rt2x00: Make rt2x00leds_register return void rt2x00dev isn't interested in the rt2x00leds_register() value anyway. So lets make it return void to even prevent people from assuming there is anybody interested in the returnvalue. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-10 05:47:08 +08:00
void rt2x00leds_register(struct rt2x00_dev *rt2x00dev);
rt2x00: Make use of MAC80211_LED_TRIGGERS Make use of the led triggers provided by mac80211 to control the led status. This can be enabled through a per-driver configuration option which will automatically enable the generic handler in rt2x00lib. This has been enabled for rt2500usb and rt73usb for the moment since the led class will call set_brightness in irq context which will not work correctly with the usb drivers who need to sleep. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-03 22:53:40 +08:00
void rt2x00leds_unregister(struct rt2x00_dev *rt2x00dev);
void rt2x00leds_suspend(struct rt2x00_dev *rt2x00dev);
void rt2x00leds_resume(struct rt2x00_dev *rt2x00dev);
#else
static inline void rt2x00leds_led_quality(struct rt2x00_dev *rt2x00dev,
int rssi)
{
}
rt2x00: Fix quality/activity led handling There was an obvious typo in LED structure initialization which caused the radio and quality/activity leds to be incorrectly initialized which resulted in the leds not being enabled. Additionally add the rt2x00led_led_activity() handler that will enable TX/RX activity leds when the radio is being enabled. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-04-22 01:01:09 +08:00
static inline void rt2x00led_led_activity(struct rt2x00_dev *rt2x00dev,
bool enabled)
{
}
rt2x00: Remove MAC80211_LEDS dependency Implement triggers inside rt2x00 itself based on input from mac80211. This replaces the method of using the mac80211 trigger events which do not work for USB drivers due to the scheduling requirement. After this patch RT2500USB_LEDS and RT73USB_LEDS no longer need to be tagged as broken since they now support LED handling again without having to check for in_atomic(). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-31 21:53:44 +08:00
static inline void rt2x00leds_led_assoc(struct rt2x00_dev *rt2x00dev,
bool enabled)
{
}
static inline void rt2x00leds_led_radio(struct rt2x00_dev *rt2x00dev,
bool enabled)
{
}
rt2x00: Make rt2x00leds_register return void rt2x00dev isn't interested in the rt2x00leds_register() value anyway. So lets make it return void to even prevent people from assuming there is anybody interested in the returnvalue. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-10 05:47:08 +08:00
static inline void rt2x00leds_register(struct rt2x00_dev *rt2x00dev)
rt2x00: Make use of MAC80211_LED_TRIGGERS Make use of the led triggers provided by mac80211 to control the led status. This can be enabled through a per-driver configuration option which will automatically enable the generic handler in rt2x00lib. This has been enabled for rt2500usb and rt73usb for the moment since the led class will call set_brightness in irq context which will not work correctly with the usb drivers who need to sleep. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-03 22:53:40 +08:00
{
}
static inline void rt2x00leds_unregister(struct rt2x00_dev *rt2x00dev)
{
}
static inline void rt2x00leds_suspend(struct rt2x00_dev *rt2x00dev)
{
}
static inline void rt2x00leds_resume(struct rt2x00_dev *rt2x00dev)
{
}
#endif /* CONFIG_RT2X00_LIB_LEDS */
[RT2x00]: add driver for Ralink wireless hardware Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26 08:57:13 +08:00
#endif /* RT2X00LIB_H */