- 31 Oct, 2008 40 commits
-
-
Johannes Berg authored
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith authored
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith authored
A warning would be printed for every packet that is transmitted if the rate control information isn't setup. Change this to WARN_ON_ONCE. Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We were also changing tx power even when we were not asked to, this enforces the change only when we are asked nicely. When not asked we simply try to use the max power, we don't tx power at all for rate control. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This enables hardware interrupt mitigation on RX. It should alleviate system interrupt load intelligently. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
sc_txintrperiod is currently set to 0 and never updated. We won't be using this, if anything we will consider using TX interrupt mitigation but that is different and not yet tested. So remove sc_txintrperiod and the pointless spin_lock_bh() on tx prepare. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We do not know what max power to allow until a device is targeting a channel, therefore only allow changing tx power if a channel is defined. Also make use of the channel's max power setting as defined by regulatory rules before allowing the user to use the requested power setting. If the user asked us to figure it out we use the max allowed by regulatory. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rami Rosen authored
This patch add a check on the return value of dev_alloc_skb() in ieee80211_sta_join_ibss() in net/mac80211/mlme.c. Signed-off-by: Rami Rosen <ramirose@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
There is quite a lot of overlap in definitions between these headers... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Also change escape_ssid to print_ssid to match print_mac semantics. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Also use common backslash sequences like \t, \n, \r, and \\ as well as \0. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
It is unnecessary and of questionable value. Also remove is_empty_ssid, as it is also unnecessary. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
We never clearly defined the semantics of the sta_notify callback and it was originally posted for iwlwifi which still doesn't use it at all. With the recent HT rework ath9k started relying on it, but I made a mistake there in that I made ath9k assume the HT information has already been filled in at sta_notify time. This isn't a hard thing to do, so do it. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhaolei authored
debugfs_create_*() returns NULL if an error occurs, returns -ENODEV when debugfs is not enabled in the kernel. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhaolei authored
debugfs_create_bool() returns NULL if an error occurs, returns -ENODEV when debugfs is not enabled in the kernel. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
http://en.wikipedia.org/wiki/De_Morgan%27s_laws is useful. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
We really only need to know the last request at each point in time. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This mutex is wrong, we use cfg80211_drv_mutex (which should possibly be renamed to just cfg80211_mutex) everywhere except in one place, fix that and get rid of the extra mutex. Also get rid of a spurious regulatory_requests list definition. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This function requires an internal lock to be held, so it cannot be published to other modules in the kernel. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bob Copeland authored
Correct a handful of errors found while reading the mac80211 book. Signed-off-by: Bob Copeland <me@bobcopeland.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John Daiker authored
A few changes to reduce checkpatch.pl errors in the rt2x00 driver. For the most part, I only fixed cosmetic things, and left the actual 'code flow' untouched (hopefully)! Diff is against wireless-testing HEAD. Signed-off-by: John Daiker <daikerjohn@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John Daiker authored
A few changes to reduce checkpatch.pl errors in the ath5k driver. For the most part, I only fixed cosmetic things, and left the actual 'code flow' untouched (hopefully)! Diff is against wireless-testing HEAD. Signed-off-by: John Daiker <daikerjohn@gmail.com> Reviewed-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
colin@cozybit.com authored
The two new commands are NL80211_CMD_GET_MESH_PARAMS and NL80211_CMD_SET_MESH_PARAMS. There is a new attribute enum, NL80211_ATTR_MESH_PARAMS, which enumerates the various mesh configuration parameters. Moved struct mesh_config from mac80211/ieee80211_i.h to net/cfg80211.h. nl80211_get_mesh_params and nl80211_set_mesh_params unpack the netlink messages and ask the driver to get or set the configuration. This is done via two new function stubs, get_mesh_params and set_mesh_params, in struct cfg80211_ops. Signed-off-by: Colin McCabe <colin@cozybit.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
I noticed that when for some reason [1] the probe or auth times out, wpa_supplicant doesn't realise this and only tries the next AP when it runs into its own timeout, which is ten seconds, and that's quite long. Fix this by making mac80211 notify userspace that it didn't associate. [1] my wrt350n in mixed B/G/HT mode often runs into this, maybe it's because one of the antennas is broken off and for whatever reason it decides to use that antenna to transmit the response frames (auth, probe); I do see beacons fine so it's not totally broken. Works fine in pure-G mode. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
A compilation with the command "make C=2 CF="-D__CHECK_ENDIAN__" \ drivers/net/wireless/hostap/" yields the following warnings: CHECK drivers/net/wireless/hostap/hostap_info.c drivers/net/wireless/hostap/hostap_info.c:156:43: warning: incorrect type in argument 2 (different signedness) drivers/net/wireless/hostap/hostap_info.c:156:43: expected unsigned long volatile *addr drivers/net/wireless/hostap/hostap_info.c:156:43: got long *<noident> drivers/net/wireless/hostap/hostap_info.c:294:44: warning: incorrect type in argument 2 (different signedness) drivers/net/wireless/hostap/hostap_info.c:294:44: expected unsigned long volatile *addr drivers/net/wireless/hostap/hostap_info.c:294:44: got long *<noident> drivers/net/wireless/hostap/hostap_info.c:487:12: warning: incorrect type in argument 2 (different signedness) drivers/net/wireless/hostap/hostap_info.c:487:12: expected unsigned long volatile *addr drivers/net/wireless/hostap/hostap_info.c:487:12: got long *<noident> drivers/net/wireless/hostap/hostap_info.c:491:12: warning: incorrect type in argument 2 (different signedness) drivers/net/wireless/hostap/hostap_info.c:491:12: expected unsigned long volatile *addr drivers/net/wireless/hostap/hostap_info.c:491:12: got long *<noident> The warnings are fixed with the following compile-tested fix: Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Jouni Malinen <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
"Clearing" the rate control algorithm is pointless, none of the algorithms actually uses this operation and it's not even invoked properly for all channel switching. Also, there's no need to since rate control algorithms work per station. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch protects iwl-csr.h and iwl-fh.h from double inclusion by ifndef define endif idiom Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
This patch enhances minstrel's performance for non-MRR setups, by preventing it from sampling slower rates with >95% success probability and by putting at least 1 non-sample frame between several sample frames. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
NLA_NESTED attributes cannot be empty, but we want to be able to specify "no flags" (empty attribute) vs. "no change" (no attribute). Therefore, remove the NLA_NESTED policy so it can work as an empty attribute. I guess I should have used a u32 for these flags instead, but we're stuck with it now. Haven't noticed earlier because of a bug in iw... Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This patch removes most/all? of the "magic" numbers and unknown structure variables inside the code and replaces them with meaningful prototypes. (Plus a one line warning fix from Larry Finger <Larry.Finger@lwfinger.net>.) Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch initialize all remaining values which are necessary for SPI firmwares. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
We have to be careful if multiple "control frames" are passed in a very short intervals to the device's firmware. As p54_assign_address always put them into same memory location. To guarantee that this won't happen anymore, we have to treat control frames like normal data frames in the devices own memory management. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
the long names and the nesting in p54_rx_frame_sent really became a "line longer than 80 characters" problem. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch series hopefully increases p54's "longterm" stability. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch makes clear that tx command is attached to the same tfd as the tx packet Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch: 1. fixes command DMA unmapping, this might be visible only on platforms where DMA unmapping is no noop such as PPC64 (not tested) 2. attaches correctly high memory part of the host command buffer 3. changes structure of TFD TB instead of describing transmit buffer (TB) tuple it describes single TB and makes code more readable on price of one unaligned access 4. eliminates using of IWL_GET/SET_BITs for TFD handling 5. renames TFD structures to mach the HW spec 6. reduces iwl_tx_info size by reserving first TB to the host command This patch should not have any visible effect on x86 32 This patch is rework of iwlwifi: fix DMA code and bugs from Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Cc: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
TX antenna toggling is requested for management frames in tx and scanning. I addition toggling in scanning was incorrect; Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch adds iwl_cmd_queue_free function and separate cmd queue freeing from regular tx queue freeing. This improves readability and adds one more step in restructuring of cmd queue handling Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-