* [PATCH, v2] libertas: sort and categorize entries in decl.h
From: Holger Schurig @ 2009-10-20 12:44 UTC (permalink / raw)
To: linux-wireless; +Cc: John Linville, Dan Williams
In-Reply-To: <200910191527.04100.hs4233@mail.mn-solutions.de>
[PATCH, v2] libertas: sort and categorize entries in decl.h
This now makes decl.h only contain declarations for functions that don't
have their own *.h file.
No functional change.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
---
v2: compilation fix
--- linux-wl.orig/drivers/net/wireless/libertas/decl.h
+++ linux-wl/drivers/net/wireless/libertas/decl.h
@@ -8,46 +8,30 @@
#include <linux/netdevice.h>
-#include "defs.h"
-
-extern const struct ethtool_ops lbs_ethtool_ops;
-
-/** Function Prototype Declaration */
struct lbs_private;
struct sk_buff;
struct net_device;
-struct cmd_ctrl_node;
-struct cmd_ds_command;
-int lbs_suspend(struct lbs_private *priv);
-void lbs_resume(struct lbs_private *priv);
-
-void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count);
-void lbs_queue_event(struct lbs_private *priv, u32 event);
-void lbs_notify_command_response(struct lbs_private *priv, u8 resp_idx);
-int lbs_enter_auto_deep_sleep(struct lbs_private *priv);
-int lbs_exit_auto_deep_sleep(struct lbs_private *priv);
+/* ethtool.c */
+extern const struct ethtool_ops lbs_ethtool_ops;
-u32 lbs_fw_index_to_data_rate(u8 index);
-u8 lbs_data_rate_to_fw_index(u32 rate);
-/** The proc fs interface */
+/* tx.c */
+void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count);
netdev_tx_t lbs_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev);
+/* rx.c */
int lbs_process_rxed_packet(struct lbs_private *priv, struct sk_buff *);
-struct chan_freq_power *lbs_find_cfp_by_band_and_channel(
- struct lbs_private *priv,
- u8 band,
- u16 channel);
/* persistcfg.c */
void lbs_persist_config_init(struct net_device *net);
void lbs_persist_config_remove(struct net_device *net);
+
/* main.c */
struct lbs_private *lbs_add_card(void *card, struct device *dmdev);
void lbs_remove_card(struct lbs_private *priv);
@@ -55,5 +39,17 @@
void lbs_stop_card(struct lbs_private *priv);
void lbs_host_to_card_done(struct lbs_private *priv);
+int lbs_suspend(struct lbs_private *priv);
+void lbs_resume(struct lbs_private *priv);
+
+void lbs_queue_event(struct lbs_private *priv, u32 event);
+void lbs_notify_command_response(struct lbs_private *priv, u8 resp_idx);
+
+int lbs_enter_auto_deep_sleep(struct lbs_private *priv);
+int lbs_exit_auto_deep_sleep(struct lbs_private *priv);
+
+u32 lbs_fw_index_to_data_rate(u8 index);
+u8 lbs_data_rate_to_fw_index(u32 rate);
+
#endif
--- linux-wl.orig/drivers/net/wireless/libertas/scan.c
+++ linux-wl/drivers/net/wireless/libertas/scan.c
@@ -12,10 +12,10 @@
#include <net/lib80211.h>
#include "host.h"
-#include "decl.h"
#include "dev.h"
#include "scan.h"
#include "assoc.h"
+#include "wext.h"
#include "cmd.h"
//! Approximate amount of data needed to pass a scan result back to iwlist
--- linux-wl.orig/drivers/net/wireless/libertas/wext.h
+++ linux-wl/drivers/net/wireless/libertas/wext.h
@@ -10,4 +10,9 @@
extern struct iw_handler_def lbs_handler_def;
extern struct iw_handler_def mesh_handler_def;
+struct chan_freq_power *lbs_find_cfp_by_band_and_channel(
+ struct lbs_private *priv,
+ u8 band,
+ u16 channel);
+
#endif
--
http://www.holgerschurig.de
^ permalink raw reply
* [PATCH] libertas: move mic failure event to wext.c
From: Holger Schurig @ 2009-10-20 13:05 UTC (permalink / raw)
To: linux-wireless, John Linville, Dan Williams
... because for cfg80211 we'll need a completely different
implementation.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
--- linux-wl.orig/drivers/net/wireless/libertas/cmdresp.c
+++ linux-wl/drivers/net/wireless/libertas/cmdresp.c
@@ -73,32 +73,6 @@
lbs_deb_leave(LBS_DEB_ASSOC);
}
-/**
- * @brief This function handles MIC failure event.
- *
- * @param priv A pointer to struct lbs_private structure
- * @para event the event id
- * @return n/a
- */
-static void handle_mic_failureevent(struct lbs_private *priv, u32 event)
-{
- char buf[50];
-
- lbs_deb_enter(LBS_DEB_CMD);
- memset(buf, 0, sizeof(buf));
-
- sprintf(buf, "%s", "MLME-MICHAELMICFAILURE.indication ");
-
- if (event == MACREG_INT_CODE_MIC_ERR_UNICAST) {
- strcat(buf, "unicast ");
- } else {
- strcat(buf, "multicast ");
- }
-
- lbs_send_iwevcustom_event(priv, buf);
- lbs_deb_leave(LBS_DEB_CMD);
-}
-
static int lbs_ret_reg_access(struct lbs_private *priv,
u16 type, struct cmd_ds_command *resp)
{
@@ -477,12 +451,12 @@
case MACREG_INT_CODE_MIC_ERR_UNICAST:
lbs_deb_cmd("EVENT: UNICAST MIC ERROR\n");
- handle_mic_failureevent(priv, MACREG_INT_CODE_MIC_ERR_UNICAST);
+ lbs_send_mic_failureevent(priv, event);
break;
case MACREG_INT_CODE_MIC_ERR_MULTICAST:
lbs_deb_cmd("EVENT: MULTICAST MIC ERROR\n");
- handle_mic_failureevent(priv, MACREG_INT_CODE_MIC_ERR_MULTICAST);
+ lbs_send_mic_failureevent(priv, event);
break;
case MACREG_INT_CODE_MIB_CHANGED:
--- linux-wl.orig/drivers/net/wireless/libertas/wext.c
+++ linux-wl/drivers/net/wireless/libertas/wext.c
@@ -54,7 +54,7 @@
wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
}
-void lbs_send_iwevcustom_event(struct lbs_private *priv, s8 *str)
+static void lbs_send_iwevcustom_event(struct lbs_private *priv, s8 *str)
{
union iwreq_data iwrq;
u8 buf[50];
@@ -79,6 +79,31 @@
}
/**
+ * @brief This function handles MIC failure event.
+ *
+ * @param priv A pointer to struct lbs_private structure
+ * @para event the event id
+ * @return n/a
+ */
+void lbs_send_mic_failureevent(struct lbs_private *priv, u32 event)
+{
+ char buf[50];
+
+ lbs_deb_enter(LBS_DEB_CMD);
+ memset(buf, 0, sizeof(buf));
+
+ sprintf(buf, "%s", "MLME-MICHAELMICFAILURE.indication ");
+
+ if (event == MACREG_INT_CODE_MIC_ERR_UNICAST)
+ strcat(buf, "unicast ");
+ else
+ strcat(buf, "multicast ");
+
+ lbs_send_iwevcustom_event(priv, buf);
+ lbs_deb_leave(LBS_DEB_CMD);
+}
+
+/**
* @brief Find the channel frequency power info with specific channel
*
* @param priv A pointer to struct lbs_private structure
--- linux-wl.orig/drivers/net/wireless/libertas/wext.h
+++ linux-wl/drivers/net/wireless/libertas/wext.h
@@ -5,7 +5,7 @@
#define _LBS_WEXT_H_
void lbs_send_disconnect_notification(struct lbs_private *priv);
-void lbs_send_iwevcustom_event(struct lbs_private *priv, s8 *str);
+void lbs_send_mic_failureevent(struct lbs_private *priv, u32 event);
extern struct iw_handler_def lbs_handler_def;
extern struct iw_handler_def mesh_handler_def;
--
http://www.holgerschurig.de
^ permalink raw reply
* l
From: Holger Schurig @ 2009-10-20 13:13 UTC (permalink / raw)
To: Andrey Yurovsky, linux-wireless, Dan Williams, John Linville
[PATCH] libertas spi: fix sparse errors
This fixes the following sparse warnings:
$ make modules SUBDIRS=drivers/net/wireless/libertas C=1 CF=-D__CHECK_ENDIAN__
make: Entering directory `/usr/src/linux-wl'
CHECK drivers/net/wireless/libertas/if_spi.c
drivers/net/wireless/libertas/if_spi.c:137:16: warning: incorrect type in initializer (different base types)
drivers/net/wireless/libertas/if_spi.c:137:16: expected unsigned short [unsigned] [usertype] reg_out
drivers/net/wireless/libertas/if_spi.c:137:16: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:191:16: warning: incorrect type in initializer (different base types)
drivers/net/wireless/libertas/if_spi.c:191:16: expected unsigned short [unsigned] [usertype] reg_out
drivers/net/wireless/libertas/if_spi.c:191:16: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:256:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:256:24: expected restricted __le32 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:256:24: got unsigned int *<noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24: expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24: got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24: expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24: got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24: expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24: got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24: expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24: got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24: expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24: got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7: expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7: got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24: expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24: got unsigned short *<noident>
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
---
Andrey, can you test this?
Dan, John: this is completely unrelated to my other libertas patches
--- linux-wl.orig/drivers/net/wireless/libertas/if_spi.c
+++ linux-wl/drivers/net/wireless/libertas/if_spi.c
@@ -134,7 +134,7 @@
static int spu_write(struct if_spi_card *card, u16 reg, const u8 *buf, int len)
{
int err = 0;
- u16 reg_out = cpu_to_le16(reg | IF_SPI_WRITE_OPERATION_MASK);
+ __le16 reg_out = cpu_to_le16(reg | IF_SPI_WRITE_OPERATION_MASK);
struct spi_message m;
struct spi_transfer reg_trans;
struct spi_transfer data_trans;
@@ -166,7 +166,7 @@
static inline int spu_write_u16(struct if_spi_card *card, u16 reg, u16 val)
{
- u16 buff;
+ __le16 buff;
buff = cpu_to_le16(val);
return spu_write(card, reg, (u8 *)&buff, sizeof(u16));
@@ -188,7 +188,7 @@
{
unsigned int delay;
int err = 0;
- u16 reg_out = cpu_to_le16(reg | IF_SPI_READ_OPERATION_MASK);
+ __le16 reg_out = cpu_to_le16(reg | IF_SPI_READ_OPERATION_MASK);
struct spi_message m;
struct spi_transfer reg_trans;
struct spi_transfer dummy_trans;
@@ -235,7 +235,7 @@
/* Read 16 bits from an SPI register */
static inline int spu_read_u16(struct if_spi_card *card, u16 reg, u16 *val)
{
- u16 buf;
+ __le16 buf;
int ret;
ret = spu_read(card, reg, (u8 *)&buf, sizeof(buf));
@@ -248,7 +248,7 @@
* The low 16 bits are read first. */
static int spu_read_u32(struct if_spi_card *card, u16 reg, u32 *val)
{
- u32 buf;
+ __le32 buf;
int err;
err = spu_read(card, reg, (u8 *)&buf, sizeof(buf));
--
http://www.holgerschurig.de
^ permalink raw reply
* AR9170 driver status
From: Valentin Manea @ 2009-10-20 13:22 UTC (permalink / raw)
To: linux-wireless
Hi,
It's a bit unclear in the Wiki page, I was wondering about the status of the
ar9170 driver, to be more specific does it support the HT features of the
802.11n standard? I'm trying to switch from the otus driver which is too
unstable to be of any real use.
Thanks,
Valentin
^ permalink raw reply
* 2.6.32-rc5-git1 -- INFO: possible circular locking dependency detected
From: Miles Lane @ 2009-10-20 13:37 UTC (permalink / raw)
To: LKML, linux-wireless, olger Schurig
Resending with wrapping off and time info removed:
[ INFO: possible circular locking dependency detected ]
2.6.32-rc5-git1 #1
-------------------------------------------------------
events/0/9 is trying to acquire lock:
(&rfkill->sync_work){+.+.+.}, at: [<c1039083>]
__cancel_work_timer+0x81/0x181
but task is already holding lock:
(&ehotk->hotplug_lock){+.+.+.}, at: [<f8587708>]
eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&ehotk->hotplug_lock){+.+.+.}:
[<c104ac60>] __lock_acquire+0x9fb/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c129e223>] __mutex_lock_common+0x39/0x375
[<c129e5ee>] mutex_lock_nested+0x2b/0x33
[<f8587708>] eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
[<f858787c>] eeepc_rfkill_set+0x1d/0x2d [eeepc_laptop]
[<f83f4a9f>] rfkill_set_block+0x6f/0xb1 [rfkill]
[<f83f4b78>] __rfkill_switch_all+0x2e/0x51 [rfkill]
[<f83f4c12>] rfkill_switch_all+0x33/0x41 [rfkill]
[<f83f51b0>] rfkill_op_handler+0xf0/0x11e [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c103b883>] kthread+0x5f/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
-> #1 (rfkill_global_mutex){+.+.+.}:
[<c104ac60>] __lock_acquire+0x9fb/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c129e223>] __mutex_lock_common+0x39/0x375
[<c129e5ee>] mutex_lock_nested+0x2b/0x33
[<f83f4c36>] rfkill_sync_work+0x16/0x35 [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c103b883>] kthread+0x5f/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
-> #0 (&rfkill->sync_work){+.+.+.}:
[<c104ab62>] __lock_acquire+0x8fd/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c10390ab>] __cancel_work_timer+0xa9/0x181
[<c103919a>] cancel_work_sync+0xa/0xc
[<f83f4e55>] rfkill_unregister+0x37/0x93 [rfkill]
[<f84d95bc>] wiphy_unregister+0x21/0x14c [cfg80211]
[<f885a0ed>] ieee80211_unregister_hw+0xa7/0xc5 [mac80211]
[<f89805d9>] ath_detach+0x73/0x11b [ath9k]
[<f898068c>] ath_cleanup+0xb/0x35 [ath9k]
[<f8987305>] ath_pci_remove+0x15/0x17 [ath9k]
[<c112c7a7>] pci_device_remove+0x19/0x39
[<c11c5076>] __device_release_driver+0x59/0x9d
[<c11c5157>] device_release_driver+0x18/0x23
[<c11c470b>] bus_remove_device+0x71/0x7e
[<c11c3425>] device_del+0xf0/0x131
[<c11c3471>] device_unregister+0xb/0x15
[<c1128d11>] pci_stop_bus_device+0x45/0x61
[<c1128d91>] pci_remove_bus_device+0xd/0x90
[<f8587780>] eeepc_rfkill_hotplug+0xbd/0xda [eeepc_laptop]
[<f858787c>] eeepc_rfkill_set+0x1d/0x2d [eeepc_laptop]
[<f83f4a9f>] rfkill_set_block+0x6f/0xb1 [rfkill]
[<f83f4b78>] __rfkill_switch_all+0x2e/0x51 [rfkill]
[<f83f4c12>] rfkill_switch_all+0x33/0x41 [rfkill]
[<f83f51b0>] rfkill_op_handler+0xf0/0x11e [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c103b883>] kthread+0x5f/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
other info that might help us debug this:
4 locks held by events/0/9:
#0: (events){+.+.+.}, at: [<c1038923>] worker_thread+0x11f/0x233
#1: ((rfkill_op_work).work){+.+.+.}, at: [<c1038923>]
worker_thread+0x11f/0x233
#2: (rfkill_global_mutex){+.+.+.}, at: [<f83f4bfd>]
rfkill_switch_all+0x1e/0x41 [rfkill]
#3: (&ehotk->hotplug_lock){+.+.+.}, at: [<f8587708>]
eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
stack backtrace:
Pid: 9, comm: events/0 Not tainted 2.6.32-rc5-git1 #1
Call Trace:
[<c129d1e0>] ? printk+0xf/0x17
[<c1049f29>] print_circular_bug+0x8a/0x96
[<c104ab62>] __lock_acquire+0x8fd/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c1039083>] ? __cancel_work_timer+0x81/0x181
[<c10390ab>] __cancel_work_timer+0xa9/0x181
[<c1039083>] ? __cancel_work_timer+0x81/0x181
[<c104974c>] ? mark_lock+0x1e/0x1e2
[<c1049953>] ? mark_held_locks+0x43/0x5b
[<c108b0d1>] ? kfree+0xbf/0xcb
[<c103919a>] cancel_work_sync+0xa/0xc
[<f83f4e55>] rfkill_unregister+0x37/0x93 [rfkill]
[<f84d95bc>] wiphy_unregister+0x21/0x14c [cfg80211]
[<c1038d10>] ? destroy_workqueue+0x72/0x77
[<f885a0ed>] ieee80211_unregister_hw+0xa7/0xc5 [mac80211]
[<f89805d9>] ath_detach+0x73/0x11b [ath9k]
[<f898068c>] ath_cleanup+0xb/0x35 [ath9k]
[<f8987305>] ath_pci_remove+0x15/0x17 [ath9k]
[<c112c7a7>] pci_device_remove+0x19/0x39
[<c11c5076>] __device_release_driver+0x59/0x9d
[<c11c5157>] device_release_driver+0x18/0x23
[<c11c470b>] bus_remove_device+0x71/0x7e
[<c11c3425>] device_del+0xf0/0x131
[<c11c3471>] device_unregister+0xb/0x15
[<c1128d11>] pci_stop_bus_device+0x45/0x61
[<c1128d91>] pci_remove_bus_device+0xd/0x90
[<f8587780>] eeepc_rfkill_hotplug+0xbd/0xda [eeepc_laptop]
[<f858787c>] eeepc_rfkill_set+0x1d/0x2d [eeepc_laptop]
[<f83f4a9f>] rfkill_set_block+0x6f/0xb1 [rfkill]
[<f83f4b78>] __rfkill_switch_all+0x2e/0x51 [rfkill]
[<f83f4c12>] rfkill_switch_all+0x33/0x41 [rfkill]
[<f83f51b0>] rfkill_op_handler+0xf0/0x11e [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c1038923>] ? worker_thread+0x11f/0x233
[<f83f50c0>] ? rfkill_op_handler+0x0/0x11e [rfkill]
[<c103ba7d>] ? autoremove_wake_function+0x0/0x2f
[<c1038804>] ? worker_thread+0x0/0x233
[<c103b883>] kthread+0x5f/0x64
[<c103b824>] ? kthread+0x0/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
^ permalink raw reply
* 2.6.32-rc5-git1 -- INFO: possible circular locking dependency detected
From: Miles Lane @ 2009-10-20 13:54 UTC (permalink / raw)
To: LKML, linux-wireless, Holger Schurig
Try one more time to get wrapping turned off. Sorry!
2.6.32-rc5-git1 #1
-------------------------------------------------------
events/0/9 is trying to acquire lock:
(&rfkill->sync_work){+.+.+.}, at: [<c1039083>]
__cancel_work_timer+0x81/0x181
but task is already holding lock:
(&ehotk->hotplug_lock){+.+.+.}, at: [<f8587708>]
eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&ehotk->hotplug_lock){+.+.+.}:
[<c104ac60>] __lock_acquire+0x9fb/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c129e223>] __mutex_lock_common+0x39/0x375
[<c129e5ee>] mutex_lock_nested+0x2b/0x33
[<f8587708>] eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
[<f858787c>] eeepc_rfkill_set+0x1d/0x2d [eeepc_laptop]
[<f83f4a9f>] rfkill_set_block+0x6f/0xb1 [rfkill]
[<f83f4b78>] __rfkill_switch_all+0x2e/0x51 [rfkill]
[<f83f4c12>] rfkill_switch_all+0x33/0x41 [rfkill]
[<f83f51b0>] rfkill_op_handler+0xf0/0x11e [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c103b883>] kthread+0x5f/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
-> #1 (rfkill_global_mutex){+.+.+.}:
[<c104ac60>] __lock_acquire+0x9fb/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c129e223>] __mutex_lock_common+0x39/0x375
[<c129e5ee>] mutex_lock_nested+0x2b/0x33
[<f83f4c36>] rfkill_sync_work+0x16/0x35 [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c103b883>] kthread+0x5f/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
-> #0 (&rfkill->sync_work){+.+.+.}:
[<c104ab62>] __lock_acquire+0x8fd/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c10390ab>] __cancel_work_timer+0xa9/0x181
[<c103919a>] cancel_work_sync+0xa/0xc
[<f83f4e55>] rfkill_unregister+0x37/0x93 [rfkill]
[<f84d95bc>] wiphy_unregister+0x21/0x14c [cfg80211]
[<f885a0ed>] ieee80211_unregister_hw+0xa7/0xc5 [mac80211]
[<f89805d9>] ath_detach+0x73/0x11b [ath9k]
[<f898068c>] ath_cleanup+0xb/0x35 [ath9k]
[<f8987305>] ath_pci_remove+0x15/0x17 [ath9k]
[<c112c7a7>] pci_device_remove+0x19/0x39
[<c11c5076>] __device_release_driver+0x59/0x9d
[<c11c5157>] device_release_driver+0x18/0x23
[<c11c470b>] bus_remove_device+0x71/0x7e
[<c11c3425>] device_del+0xf0/0x131
[<c11c3471>] device_unregister+0xb/0x15
[<c1128d11>] pci_stop_bus_device+0x45/0x61
[<c1128d91>] pci_remove_bus_device+0xd/0x90
[<f8587780>] eeepc_rfkill_hotplug+0xbd/0xda [eeepc_laptop]
[<f858787c>] eeepc_rfkill_set+0x1d/0x2d [eeepc_laptop]
[<f83f4a9f>] rfkill_set_block+0x6f/0xb1 [rfkill]
[<f83f4b78>] __rfkill_switch_all+0x2e/0x51 [rfkill]
[<f83f4c12>] rfkill_switch_all+0x33/0x41 [rfkill]
[<f83f51b0>] rfkill_op_handler+0xf0/0x11e [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c103b883>] kthread+0x5f/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
other info that might help us debug this:
4 locks held by events/0/9:
#0: (events){+.+.+.}, at: [<c1038923>] worker_thread+0x11f/0x233
#1: ((rfkill_op_work).work){+.+.+.}, at: [<c1038923>]
worker_thread+0x11f/0x233
#2: (rfkill_global_mutex){+.+.+.}, at: [<f83f4bfd>]
rfkill_switch_all+0x1e/0x41 [rfkill]
#3: (&ehotk->hotplug_lock){+.+.+.}, at: [<f8587708>]
eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
stack backtrace:
Pid: 9, comm: events/0 Not tainted 2.6.32-rc5-git1 #1
Call Trace:
[<c129d1e0>] ? printk+0xf/0x17
[<c1049f29>] print_circular_bug+0x8a/0x96
[<c104ab62>] __lock_acquire+0x8fd/0xb6d
[<c104ae2e>] lock_acquire+0x5c/0x73
[<c1039083>] ? __cancel_work_timer+0x81/0x181
[<c10390ab>] __cancel_work_timer+0xa9/0x181
[<c1039083>] ? __cancel_work_timer+0x81/0x181
[<c104974c>] ? mark_lock+0x1e/0x1e2
[<c1049953>] ? mark_held_locks+0x43/0x5b
[<c108b0d1>] ? kfree+0xbf/0xcb
[<c103919a>] cancel_work_sync+0xa/0xc
[<f83f4e55>] rfkill_unregister+0x37/0x93 [rfkill]
[<f84d95bc>] wiphy_unregister+0x21/0x14c [cfg80211]
[<c1038d10>] ? destroy_workqueue+0x72/0x77
[<f885a0ed>] ieee80211_unregister_hw+0xa7/0xc5 [mac80211]
[<f89805d9>] ath_detach+0x73/0x11b [ath9k]
[<f898068c>] ath_cleanup+0xb/0x35 [ath9k]
[<f8987305>] ath_pci_remove+0x15/0x17 [ath9k]
[<c112c7a7>] pci_device_remove+0x19/0x39
[<c11c5076>] __device_release_driver+0x59/0x9d
[<c11c5157>] device_release_driver+0x18/0x23
[<c11c470b>] bus_remove_device+0x71/0x7e
[<c11c3425>] device_del+0xf0/0x131
[<c11c3471>] device_unregister+0xb/0x15
[<c1128d11>] pci_stop_bus_device+0x45/0x61
[<c1128d91>] pci_remove_bus_device+0xd/0x90
[<f8587780>] eeepc_rfkill_hotplug+0xbd/0xda [eeepc_laptop]
[<f858787c>] eeepc_rfkill_set+0x1d/0x2d [eeepc_laptop]
[<f83f4a9f>] rfkill_set_block+0x6f/0xb1 [rfkill]
[<f83f4b78>] __rfkill_switch_all+0x2e/0x51 [rfkill]
[<f83f4c12>] rfkill_switch_all+0x33/0x41 [rfkill]
[<f83f51b0>] rfkill_op_handler+0xf0/0x11e [rfkill]
[<c1038965>] worker_thread+0x161/0x233
[<c1038923>] ? worker_thread+0x11f/0x233
[<f83f50c0>] ? rfkill_op_handler+0x0/0x11e [rfkill]
[<c103ba7d>] ? autoremove_wake_function+0x0/0x2f
[<c1038804>] ? worker_thread+0x0/0x233
[<c103b883>] kthread+0x5f/0x64
[<c103b824>] ? kthread+0x0/0x64
[<c1003613>] kernel_thread_helper+0x7/0x10
^ permalink raw reply
* Rate information in ad-hoc and mesh mode
From: Charles Gordon @ 2009-10-20 14:10 UTC (permalink / raw)
To: linux-wireless
I notice that the ieee80211_ioctl_giwrate function in wext.c only
returns rate information for stations associated to an AP. It does
not return rate information for stations operating in ad-hoc mode or
as a mesh point. Is there a reason this function is not supported in
those modes? Is this a deliberate decision or just an oversight?
Thanks for your help.
^ permalink raw reply
* mac80211/ath9k/hostapd: Some clients unable to associate with AP
From: Björn Smedman @ 2009-10-20 14:11 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Hi all,
I'm trying to update from compat-wireless-2009-06-02 to
compat-wireless-2.6.32-rc1. After the update some clients can
no-longer associate with the access point (mac80211/ath9k/hostapd).
Specifically, it seems windows based clients do not accept the new
association response frame and choke or send deauth.
A tcpdump from a separate machine shows the story. After the update
with compat-wireless-2.6.32-rc1 the dump locks like this (notice the
deauth frame from the XP laptop at the end):
19:59:18.973699 1573025241us tsft 1.0 Mb/s 2412 MHz (0x0080) -53dB
signal 0dB noise antenna 0 BSSID:ff:ff:ff:ff:ff:ff
DA:ff:ff:ff:ff:ff:ff SA:00:13:02:36:ab:37 Probe Request
(demo.venatech.net) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
19:59:18.975919 1573026699us tsft 1.0 Mb/s 2412 MHz (0x0080) -57dB
signal 0dB noise antenna 0 BSSID:00:23:cd:de:2f:c5
DA:00:13:02:36:ab:37 SA:00:23:cd:de:2f:c5 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
19:59:18.977723 1573028524us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
19:59:18.981060 1573031853us tsft 1.0 Mb/s 2412 MHz (0x0080) -67dB
signal 0dB noise antenna 0 BSSID:00:23:cd:c7:c3:fd
DA:00:13:02:36:ab:37 SA:00:23:cd:c7:c3:fd Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
19:59:19.019827 1573071924us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -53dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 Authentication (Open
System)-1: Succesful
19:59:19.022448 1573074291us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Authentication (Open
System)-2:
19:59:19.022963 1573075062us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -52dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 Assoc Request
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit]
19:59:19.096487 1573147524us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Assoc Response AID(2) ::
Succesful
19:59:19.227409 1573279582us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -52dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 DeAuthentication:
Unspecified reason
With compat-wireless-2009-06-02 the (successful) dump locks like this:
20:01:56.525502 433315165us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:ff:ff:ff:ff:ff:ff
DA:ff:ff:ff:ff:ff:ff SA:00:13:02:36:ab:37 Probe Request
(demo.venatech.net) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
20:01:56.527462 433316613us tsft 1.0 Mb/s 2412 MHz (0x0080) -44dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
20:01:56.541231 433330271us tsft 1.0 Mb/s 2412 MHz (0x0080) -44dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
20:01:56.542509 433331546us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
20:01:56.543874 433332939us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
20:01:56.545297 433334332us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
20:01:56.556071 433346142us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -41dB signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:25:86:d9:61:a7 SA:00:13:02:36:ab:37 Authentication (Open
System)-1: Succesful
20:01:56.558199 433347993us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Authentication (Open
System)-2:
20:01:56.558653 433348766us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -41dB signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:25:86:d9:61:a7 SA:00:13:02:36:ab:37 Assoc Request
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit]
20:01:56.634096 433423226us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Assoc Response AID(2) ::
Succesful
I've also tried some other windows based clients, e.g. a laptop with
an old 11b 3Com PCMCIA card. Most seem to choke from the auth response
or assoc response frame. The hostapd/syslog on the AP side looks
something like this:
MGMT
mgmt::auth
authentication: STA=00:04:75:c4:1e:a5 auth_alg=0 auth_transaction=1
status_code=0 wep=0
ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authentication OK (open system)
ap0: STA 00:04:75:c4:1e:a5 MLME:
MLME-AUTHENTICATE.indication(00:04:75:c4:1e:a5, OPEN_SYSTEM)
ap0: STA 00:04:75:c4:1e:a5 MLME: MLME-DELETEKEYS.request(00:04:75:c4:1e:a5)
authentication reply: STA=00:04:75:c4:1e:a5 auth_alg=0
auth_transaction=2 resp=0 (IE len=0)
MGMT (TX callback) ACK
mgmt::auth cb
ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authenticated
Jan 1 03:33:12 00:23:CD:DA:3C:04 daemon.info hostapd: ap0: STA
00:04:75:c4:1e:a5 IEEE 802.11: authenticated
STA 00:04:75:c4:1e:a5 sent probe request for broadcast SSID
STA 00:04:75:c4:1e:a5 sent probe request for our SSID
MGMT (TX callback) fail
mgmt::proberesp cb
MGMT (TX callback) fail
mgmt::proberesp cb
MGMT
mgmt::auth
authentication: STA=00:04:75:c4:1e:a5 auth_alg=0 auth_transaction=1
status_code=0 wep=0
ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authentication OK (open system)
ap0: STA 00:04:75:c4:1e:a5 MLME:
MLME-AUTHENTICATE.indication(00:04:75:c4:1e:a5, OPEN_SYSTEM)
ap0: STA 00:04:75:c4:1e:a5 MLME: MLME-DELETEKEYS.request(00:04:75:c4:1e:a5)
authentication reply: STA=00:04:75:c4:1e:a5 auth_alg=0
auth_transaction=2 resp=0 (IE len=0)
STA 00:22:fa:f8:17:c8 sent probe request for broadcast SSID
MGMT (TX callback) ACK
mgmt::auth cb
ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authenticated
[And so on over and over...]
I've also tried some different versions of hostapd: 0.6.9 and two
different git snapshots from 0.7-branch (a35187e71a1dd23653fc03ed5
and 6d6f4bb87f33278aed133875d0d561eb55d7ae59) but it doesn't seem to
make any difference. My configuration file is really simple:
driver=nl80211
interface=ap0
ctrl_interface=/var/run/
hostapd-vtmd
hw_mode=g
channel=1
ssid=demo.venatech.net
ieee80211n=1
ht_capab=
Does anybody recognize this? Any ideas on what to try next? Any help
would be greatly appreciated.
/Björn
^ permalink raw reply
* Re: Rate information in ad-hoc and mesh mode
From: Holger Schurig @ 2009-10-20 15:14 UTC (permalink / raw)
To: Charles Gordon; +Cc: linux-wireless
In-Reply-To: <86201b3f0910200710u36557bf8uf5bc014b32b14d33@mail.gmail.com>
> I notice that the ieee80211_ioctl_giwrate function in wext.c only
> returns rate information for stations associated to an AP. It does
> not return rate information for stations operating in ad-hoc mode or
> as a mesh point. Is there a reason this function is not supported in
> those modes? Is this a deliberate decision or just an oversight?
You need to give more context. What driver, what kernel?
A quick
ack-grep ieee80211_ioctl_giwrate include/net include/linux \
net/wireless net/mac80211 \
drivers/net/wireless
didn't reveal the function you've mentioned, at least not in the
current wireless-testing kernel.
--
http://www.holgerschurig.de
^ permalink raw reply
* Wrong BSSID generation in IBSS mode with ath5k
From: Karol Pucyński @ 2009-10-20 15:27 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi
I have IBSS network (based on ath5k cards).
With the same channel/essid set cards often can't "negotiate" the
same BSSID. Two nodes beside each other both create new IBSS networks
and they are not trying to merge.
Workaround: forcing BSSID with iw does work.
Do you know what can be the reason of this problem?
Tested on 2.6.31 kernel. May be related to my earlier problem 'ath5k
IBSS fixed rate'...
Best regards
--
Karol Pucyński
7bulls.com Sp. z o.o.
kpucynski@7bulls.com
[-- Attachment #2: To jest część wiadomości podpisana cyfrowo --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Question about getting TX queue parameter
From: Jinsung Lee @ 2009-10-20 15:39 UTC (permalink / raw)
To: linux-wireless
Dear all,
I found the nice patch as follows:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=
318884875bdddca663ecc373c813cf8e117d9e43
This patch enables to set TX queue parameters such as txop, cwmin, cwmax and
aifs using NL80211_CMD_SET_WIPHY for userspace command (e.g.., iw).
I'm wondering if the above patch already includes the potential of getting
TX queue parameters using NL80211_CMD_GET_WIPHY for userspace command.
Does anyone have some idea for this?
Thanks.
--
Regards,
Jinsung Lee
--
^ permalink raw reply
* Re: Rate information in ad-hoc and mesh mode
From: Charles Gordon @ 2009-10-20 15:41 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <200910201714.34866.hs4233@mail.mn-solutions.de>
I am using version 2.6.28 of the kernel. We are using our own
wireless driver. However, the problem does not appear to be in the
driver. The iw utility uses the SIOCGIWRATE ioctl to get rate
information. This ioctl is handled by the ieee80211_ioctl_giwrate
function in net/mac80211/wext.c in the 2.6.28 version of the kernel.
This function returns immediately if sdata->vif.type !=
NL80211_IFTYPE_STATION, which will be the case for ad-hoc mode.
On Tue, Oct 20, 2009 at 11:14 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
>> I notice that the ieee80211_ioctl_giwrate function in wext.c only
>> returns rate information for stations associated to an AP. It does
>> not return rate information for stations operating in ad-hoc mode or
>> as a mesh point. Is there a reason this function is not supported in
>> those modes? Is this a deliberate decision or just an oversight?
>
> You need to give more context. What driver, what kernel?
>
>
> A quick
>
> ack-grep ieee80211_ioctl_giwrate include/net include/linux \
> net/wireless net/mac80211 \
> drivers/net/wireless
>
> didn't reveal the function you've mentioned, at least not in the
> current wireless-testing kernel.
>
> --
> http://www.holgerschurig.de
>
^ permalink raw reply
* ath5k IBSS fixed rate
From: Karol Pucyński @ 2009-10-20 15:20 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
Hi
I'm trying to set up IBSS network using ath5k cards.
I'm using iwconfig to set fixed bitrate on cards, but setting it does
not have effect. When I set it with, for example, 'iwconfig wlan0 rate
1M', card is still trying to auto negotiate bitrate.
'iw wlan0 station dump' shows that it is using other (higher) bitrate
and falling down to 11M or 1M.
How can I force bitrate to use? Is there any other way?
It's bug or feature? ;)
Best regards
--
Karol Pucyński
7bulls.com Sp. z o.o.
kpucynski@7bulls.com
[-- Attachment #2: To jest część wiadomości podpisana cyfrowo --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Test for N-mode from userspace?
From: Kunal Gangakhedkar @ 2009-10-20 15:42 UTC (permalink / raw)
To: ath9k-devel; +Cc: linux-wireless
Hi,
Is it possible to check for whether the N-mode is alive on the laptop and not
blocked by the OEM (HP)?
I don't have access to an N-mode AP to try to associate and check; but I'm
planning to buy a new AP/router - so, might as well go for one having N-mode
now that it's standardised.
The device I have is AR9285 - which does have N mode support as per the
following iwconfig output:
kunal@plutonium:~$ iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"Kunal-home"
Mode:Managed Frequency:2.432 GHz Access Point: 00:1A:70:EE:8D:62
Bit Rate=5.5 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=70/70 Signal level=-35 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
lspci -v output:
08:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless
Network Adapter (PCI-Express) (rev 01)
Subsystem: Hewlett-Packard Company Device 3040
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at d1200000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0Enable-
Capabilities: [60] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 12-14-24-ff-ff-17-15-00
Capabilities: [170] Power Budgeting <?>
Kernel driver in use: ath9k
Kernel modules: ath9k
iw list output:
Wiphy phy0
Band 1:
HT capabilities: 0x104e
* 20/40 MHz operation
* SM PS disabled
* 40 MHz short GI
* max A-MSDU len 3839
* DSSS/CCK 40 MHz
HT A-MPDU factor: 0x0003 (65535 bytes)
HT A-MPDU density: 0x0006 (8 usec)
HT MCS set: ff 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
HT TX/RX MCS rate indexes supported:
MCS index 0
MCS index 1
MCS index 2
MCS index 3
MCS index 4
MCS index 5
MCS index 6
MCS index 7
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (passive scanning)
* 2472 MHz [13] (20.0 dBm) (passive scanning)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Thanks,
Kunal
^ permalink raw reply
* Re: [PATCH, v2] libertas: move SIOCGIWAP calls to wext.c
From: Randy Dunlap @ 2009-10-20 15:53 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John Linville, Dan Williams
In-Reply-To: <200910201439.31384.hs4233@mail.mn-solutions.de>
On Tue, 20 Oct 2009 14:39:31 +0200 Holger Schurig wrote:
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
>
> ---
> v1: Less and less files now depend on WEXT :-)
> v2: fix compilation issue
You should say what compilation issue it fixes.
> --- linux-wl.orig/drivers/net/wireless/libertas/cmdresp.c
> +++ linux-wl/drivers/net/wireless/libertas/cmdresp.c
> @@ -27,23 +27,18 @@
> */
> void lbs_mac_event_disconnected(struct lbs_private *priv)
> {
> - union iwreq_data wrqu;
> -
> if (priv->connect_status != LBS_CONNECTED)
> return;
>
> lbs_deb_enter(LBS_DEB_ASSOC);
>
> - memset(wrqu.ap_addr.sa_data, 0x00, ETH_ALEN);
> - wrqu.ap_addr.sa_family = ARPHRD_ETHER;
>
> /*
> * Cisco AP sends EAP failure and de-auth in less than 0.5 ms.
> * It causes problem in the Supplicant
> */
> -
> msleep_interruptible(1000);
> - wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
> + lbs_send_disconnect_notification(priv);
>
> /* report disconnect to upper layer */
> netif_stop_queue(priv->dev);
> --- linux-wl.orig/drivers/net/wireless/libertas/main.c
> +++ linux-wl/drivers/net/wireless/libertas/main.c
> @@ -1227,7 +1227,6 @@
> void lbs_remove_card(struct lbs_private *priv)
> {
> struct net_device *dev = priv->dev;
> - union iwreq_data wrqu;
>
> lbs_deb_enter(LBS_DEB_MAIN);
>
> @@ -1252,9 +1251,7 @@
> lbs_ps_wakeup(priv, CMD_OPTION_WAITFORRSP);
> }
>
> - memset(wrqu.ap_addr.sa_data, 0xaa, ETH_ALEN);
> - wrqu.ap_addr.sa_family = ARPHRD_ETHER;
> - wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
> + lbs_send_disconnect_notification(priv);
>
> if (priv->is_deep_sleep) {
> priv->is_deep_sleep = 0;
> --- linux-wl.orig/drivers/net/wireless/libertas/wext.c
> +++ linux-wl/drivers/net/wireless/libertas/wext.c
> @@ -45,6 +45,15 @@
> priv->pending_assoc_req = NULL;
> }
>
> +void lbs_send_disconnect_notification(struct lbs_private *priv)
> +{
> + union iwreq_data wrqu;
> +
> + memset(wrqu.ap_addr.sa_data, 0x00, ETH_ALEN);
> + wrqu.ap_addr.sa_family = ARPHRD_ETHER;
> + wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
> +}
> +
> void lbs_send_iwevcustom_event(struct lbs_private *priv, s8 *str)
> {
> union iwreq_data iwrq;
> --- linux-wl.orig/drivers/net/wireless/libertas/wext.h
> +++ linux-wl/drivers/net/wireless/libertas/wext.h
> @@ -4,6 +4,7 @@
> #ifndef _LBS_WEXT_H_
> #define _LBS_WEXT_H_
>
> +void lbs_send_disconnect_notification(struct lbs_private *priv);
> void lbs_send_iwevcustom_event(struct lbs_private *priv, s8 *str);
>
> extern struct iw_handler_def lbs_handler_def;
>
>
> --
---
~Randy
^ permalink raw reply
* Re: [PATCH] libertas: move mic failure event to wext.c
From: Randy Dunlap @ 2009-10-20 15:54 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John Linville, Dan Williams
In-Reply-To: <200910201505.14283.hs4233@mail.mn-solutions.de>
On Tue, 20 Oct 2009 15:05:14 +0200 Holger Schurig wrote:
> ... because for cfg80211 we'll need a completely different
> implementation.
>
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
>
> --- linux-wl.orig/drivers/net/wireless/libertas/cmdresp.c
> +++ linux-wl/drivers/net/wireless/libertas/cmdresp.c
> @@ -73,32 +73,6 @@
> lbs_deb_leave(LBS_DEB_ASSOC);
> }
>
> -/**
> - * @brief This function handles MIC failure event.
> - *
> - * @param priv A pointer to struct lbs_private structure
> - * @para event the event id
> - * @return n/a
> - */
> -static void handle_mic_failureevent(struct lbs_private *priv, u32 event)
> -{
> - char buf[50];
> -
> - lbs_deb_enter(LBS_DEB_CMD);
> - memset(buf, 0, sizeof(buf));
> -
> - sprintf(buf, "%s", "MLME-MICHAELMICFAILURE.indication ");
> -
> - if (event == MACREG_INT_CODE_MIC_ERR_UNICAST) {
> - strcat(buf, "unicast ");
> - } else {
> - strcat(buf, "multicast ");
> - }
> -
> - lbs_send_iwevcustom_event(priv, buf);
> - lbs_deb_leave(LBS_DEB_CMD);
> -}
> -
> static int lbs_ret_reg_access(struct lbs_private *priv,
> u16 type, struct cmd_ds_command *resp)
> {
> @@ -477,12 +451,12 @@
>
> case MACREG_INT_CODE_MIC_ERR_UNICAST:
> lbs_deb_cmd("EVENT: UNICAST MIC ERROR\n");
> - handle_mic_failureevent(priv, MACREG_INT_CODE_MIC_ERR_UNICAST);
> + lbs_send_mic_failureevent(priv, event);
> break;
>
> case MACREG_INT_CODE_MIC_ERR_MULTICAST:
> lbs_deb_cmd("EVENT: MULTICAST MIC ERROR\n");
> - handle_mic_failureevent(priv, MACREG_INT_CODE_MIC_ERR_MULTICAST);
> + lbs_send_mic_failureevent(priv, event);
> break;
>
> case MACREG_INT_CODE_MIB_CHANGED:
> --- linux-wl.orig/drivers/net/wireless/libertas/wext.c
> +++ linux-wl/drivers/net/wireless/libertas/wext.c
> @@ -54,7 +54,7 @@
> wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
> }
>
> -void lbs_send_iwevcustom_event(struct lbs_private *priv, s8 *str)
> +static void lbs_send_iwevcustom_event(struct lbs_private *priv, s8 *str)
> {
> union iwreq_data iwrq;
> u8 buf[50];
> @@ -79,6 +79,31 @@
> }
>
> /**
> + * @brief This function handles MIC failure event.
> + *
> + * @param priv A pointer to struct lbs_private structure
> + * @para event the event id
> + * @return n/a
> + */
argh. urgh. This file (or files) need to lose this non-kernel-doc
function notation. Please.
> +void lbs_send_mic_failureevent(struct lbs_private *priv, u32 event)
> +{
> + char buf[50];
> +
> + lbs_deb_enter(LBS_DEB_CMD);
> + memset(buf, 0, sizeof(buf));
> +
> + sprintf(buf, "%s", "MLME-MICHAELMICFAILURE.indication ");
> +
> + if (event == MACREG_INT_CODE_MIC_ERR_UNICAST)
> + strcat(buf, "unicast ");
> + else
> + strcat(buf, "multicast ");
> +
> + lbs_send_iwevcustom_event(priv, buf);
> + lbs_deb_leave(LBS_DEB_CMD);
> +}
> +
> +/**
> * @brief Find the channel frequency power info with specific channel
> *
> * @param priv A pointer to struct lbs_private structure
---
~Randy
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Ivo van Doorn @ 2009-10-20 16:31 UTC (permalink / raw)
To: Holger Schurig
Cc: Bartlomiej Zolnierkiewicz, John Linville, linux-wireless, users,
Alban Browaeys, Benoit PAPILLAULT, Felix Fietkau, Luis Correia,
Mattias Nissler, Mark Asselstine, Xose Vazquez Perez,
linux-kernel
In-Reply-To: <200910200858.54683.hs4233@mail.mn-solutions.de>
On Tuesday 20 October 2009, Holger Schurig wrote:
> > I don't agree on this, for starters the whole "abstraction
> > layer as done in the staging driver, really obfuscated the code
> > in multiple areas
>
> Ivo, you could look at Orinoco or Libertas. Both WLAN drivers
> support a multitude of different hardware (Libertas: CF/PCMCIA,
> SDIO, SD, USB and Orinoco: CF/PCMCIA, PCI, PPC_PMAC). And both
> have hardware abstraction layers that don't suck, obfuscate or
> create lots of duplicate code.
Thanks,
> So AFAIK it's not the question *IF* to do hardware abstraction
> but only a question *HOW* to do it in an intelligent way. Don't
> luck at one bad implementation and disregard the whole
> concept :-)
Oh I completely agree, I am not against the extra abstraction layer,
but I do want a nice looking solution. :) I'll take a look at the Orinoco approach.
Thanks,
Ivo
^ permalink raw reply
* Re: Wrong BSSID generation in IBSS mode with ath5k
From: reinette chatre @ 2009-10-20 17:16 UTC (permalink / raw)
To: Karol Pucyński; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1256052469.6550.7.camel@kpucynski-laptop>
On Tue, 2009-10-20 at 08:27 -0700, Karol Pucyński wrote:
> I have IBSS network (based on ath5k cards).
> With the same channel/essid set cards often can't "negotiate" the
> same BSSID. Two nodes beside each other both create new IBSS networks
> and they are not trying to merge.
> Workaround: forcing BSSID with iw does work.
>
> Do you know what can be the reason of this problem?
>
> Tested on 2.6.31 kernel. May be related to my earlier problem 'ath5k
> IBSS fixed rate'...
Are you using compat-wireless? If not, then ignore this email.
If you are using the latest wireless bits using compat-wireless then you
may have run into this issue
http://thread.gmane.org/gmane.linux.kernel.wireless.general/41129
Reinette
^ permalink raw reply
* Re: 'linux-wireless@vger.kernel.org'
From: reinette chatre @ 2009-10-20 17:28 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Sedat Dilek, Kristofik, Juraj, linux-wireless@vger.kernel.org
In-Reply-To: <3ace41890910200345i7ca796b2s9b26a6f465d066db@mail.gmail.com>
On Tue, 2009-10-20 at 03:45 -0700, Hin-Tak Leung wrote:
> Error 17 is "File Exists" apparently - I am not the author of the said
> relevant code, and I am just writing of my understanding of it -
> Feel free to have a go yourself - it is at net/mac80211/main.c .
>
This problem showed up before when a user was testing from
compat-wireless. Moving to wireless-testing resolved the issue. The
thread is at
http://thread.gmane.org/gmane.linux.kernel.wireless.general/35983
Reinette
^ permalink raw reply
* Re: [ath9k-devel] Test for N-mode from userspace?
From: xxiao @ 2009-10-20 17:28 UTC (permalink / raw)
To: ath9k-devel, Kunal Gangakhedkar; +Cc: linux-wireless
In-Reply-To: <200910202112.30660.kunal.gangakhedkar@gmail.com>
interesting, why is MCS range just 0-7, which means no HT?
xxiao
--- On Tue, 10/20/09, Kunal Gangakhedkar <kunal.gangakhedkar@gmail.com> wrote:
> From: Kunal Gangakhedkar <kunal.gangakhedkar@gmail.com>
> Subject: [ath9k-devel] Test for N-mode from userspace?
> To: ath9k-devel@lists.ath9k.org
> Cc: "linux-wireless" <linux-wireless@vger.kernel.org>
> Date: Tuesday, October 20, 2009, 10:42 AM
> Hi,
>
> Is it possible to check for whether the N-mode is alive on
> the laptop and not
> blocked by the OEM (HP)?
>
> I don't have access to an N-mode AP to try to associate and
> check; but I'm
> planning to buy a new AP/router - so, might as well go for
> one having N-mode
> now that it's standardised.
>
> The device I have is AR9285 - which does have N mode
> support as per the
> following iwconfig output:
>
> kunal@plutonium:~$ iwconfig wlan0
> wlan0 IEEE 802.11bgn
> ESSID:"Kunal-home"
> Mode:Managed
> Frequency:2.432 GHz Access Point: 00:1A:70:EE:8D:62
> Bit Rate=5.5
> Mb/s Tx-Power=20 dBm
> Retry long
> limit:7 RTS
> thr:off Fragment thr:off
> Power Management:on
> Link Quality=70/70
> Signal level=-35 dBm
> Rx invalid nwid:0
> Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive
> retries:0 Invalid misc:0 Missed
> beacon:0
>
>
> lspci -v output:
> 08:00.0 Network controller: Atheros Communications Inc.
> AR9285 Wireless
> Network Adapter (PCI-Express) (rev 01)
>
>
>
> Subsystem: Hewlett-Packard
> Company Device 3040
> Flags: bus master, fast devsel,
> latency 0, IRQ 17
> Memory at d1200000 (64-bit,
> non-prefetchable) [size=64K]
> Capabilities: [40] Power
> Management version 3
> Capabilities: [50] Message
> Signalled Interrupts: Mask- 64bit-
> Queue=0/0Enable-
> Capabilities: [60] Express
> Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced
> Error Reporting <?>
> Capabilities: [140] Virtual
> Channel <?>
> Capabilities: [160] Device
> Serial Number 12-14-24-ff-ff-17-15-00
> Capabilities: [170] Power
> Budgeting <?>
> Kernel driver in use: ath9k
> Kernel modules: ath9k
>
>
> iw list output:
> Wiphy phy0
>
>
>
> Band 1:
>
>
>
> HT
> capabilities: 0x104e
>
>
> * 20/40 MHz operation
>
>
> * SM PS disabled
>
>
> * 40 MHz short GI
>
>
> * max A-MSDU len 3839
>
>
> * DSSS/CCK 40 MHz
>
> HT
> A-MPDU factor: 0x0003 (65535 bytes)
> HT
> A-MPDU density: 0x0006 (8 usec)
>
> HT
> MCS set: ff 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
> HT
> TX/RX MCS rate indexes supported:
>
>
>
> MCS index 0
>
>
>
>
> MCS index 1
>
>
>
>
> MCS index 2
>
>
>
>
> MCS index 3
>
>
>
>
> MCS index 4
>
>
>
>
> MCS index 5
>
>
>
>
> MCS index 6
>
>
>
>
> MCS index 7
>
>
>
>
> Frequencies:
>
>
>
>
> * 2412 MHz [1] (20.0 dBm)
>
>
>
> * 2417 MHz [2] (20.0 dBm)
>
> * 2422 MHz [3] (20.0 dBm)
>
> * 2427 MHz [4] (20.0 dBm)
>
> * 2432 MHz [5] (20.0 dBm)
>
> * 2437 MHz [6] (20.0 dBm)
>
> * 2442 MHz [7] (20.0 dBm)
>
> * 2447 MHz [8] (20.0 dBm)
>
> * 2452 MHz [9] (20.0 dBm)
>
> * 2457 MHz [10] (20.0 dBm)
>
> * 2462 MHz [11] (20.0 dBm)
>
> * 2467 MHz [12] (20.0 dBm)
> (passive scanning)
>
> * 2472 MHz [13] (20.0 dBm)
> (passive scanning)
>
> * 2484 MHz [14] (disabled)
>
> Bitrates (non-HT):
>
> * 1.0 Mbps
>
> * 2.0 Mbps (short preamble
> supported)
>
> * 5.5 Mbps (short preamble
> supported)
>
> * 11.0 Mbps (short preamble
> supported)
>
> * 6.0 Mbps
>
> * 9.0 Mbps
>
> * 12.0 Mbps
>
> * 18.0 Mbps
>
> * 24.0 Mbps
>
> * 36.0 Mbps
>
> * 48.0 Mbps
>
> * 54.0 Mbps
> max # scan SSIDs: 4
> Supported interface modes:
>
> * IBSS
>
> * managed
>
> * AP
>
> * AP/VLAN
>
> * monitor
>
> * mesh point
>
> Thanks,
> Kunal
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
^ permalink raw reply
* [PATCH] mac80211: trivial: fix spelling in mesh_hwmp
From: Andrey Yurovsky @ 2009-10-20 18:04 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Andrey Yurovsky
Fix a couple of typos in the description of hwmp_route_info_get(), no
functional changes.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
---
net/mac80211/mesh_hwmp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index e12a786..c300911 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -259,12 +259,12 @@ static u32 airtime_link_metric_get(struct ieee80211_local *local,
* @hwmp_ie: hwmp information element (PREP or PREQ)
*
* This function updates the path routing information to the originator and the
- * transmitter of a HWMP PREQ or PREP fram.
+ * transmitter of a HWMP PREQ or PREP frame.
*
* Returns: metric to frame originator or 0 if the frame should not be further
* processed
*
- * Notes: this function is the only place (besides user-provided info) where
+ * Notes: this function is the only place (beside user-provided info) where
* path routing information is updated.
*/
static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] mac80211: trivial: fix spelling in mesh_hwmp
From: Randy Dunlap @ 2009-10-20 18:07 UTC (permalink / raw)
To: Andrey Yurovsky; +Cc: linux-wireless, johannes
In-Reply-To: <1256061862-23368-1-git-send-email-andrey@cozybit.com>
On Tue, 20 Oct 2009 11:04:22 -0700 Andrey Yurovsky wrote:
> Fix a couple of typos in the description of hwmp_route_info_get(), no
> functional changes.
>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
> ---
> net/mac80211/mesh_hwmp.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
> index e12a786..c300911 100644
> --- a/net/mac80211/mesh_hwmp.c
> +++ b/net/mac80211/mesh_hwmp.c
> @@ -259,12 +259,12 @@ static u32 airtime_link_metric_get(struct ieee80211_local *local,
> * @hwmp_ie: hwmp information element (PREP or PREQ)
> *
> * This function updates the path routing information to the originator and the
> - * transmitter of a HWMP PREQ or PREP fram.
> + * transmitter of a HWMP PREQ or PREP frame.
> *
> * Returns: metric to frame originator or 0 if the frame should not be further
> * processed
> *
> - * Notes: this function is the only place (besides user-provided info) where
> + * Notes: this function is the only place (beside user-provided info) where
This one was OK as is. "besides" means "other than" or "except".
> * path routing information is updated.
> */
> static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
> --
---
~Randy
^ permalink raw reply
* Re: [ath9k-devel] Test for N-mode from userspace?
From: Kunal Gangakhedkar @ 2009-10-20 18:26 UTC (permalink / raw)
To: austinxxh-ath9k; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <411169.20125.qm@web55305.mail.re4.yahoo.com>
On Tuesday 20 Oct 2009 10:58:31 pm xxiao wrote:
> interesting, why is MCS range just 0-7, which means no HT?
>
> xxiao
>
I have no clue why it's that way - I don't even know what HT means in wireless
context :)
Sorry, I'm just an end-user in this respect ..
Kunal
^ permalink raw reply
* [PATCH] mac80211: trivial: fix spelling in mesh_hwmp
From: Andrey Yurovsky @ 2009-10-20 19:17 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Andrey Yurovsky
In-Reply-To: <20091020110735.445205d1.rdunlap@xenotime.net>
Fix a typo in the description of hwmp_route_info_get(), no function
changes.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
---
net/mac80211/mesh_hwmp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index e12a786..29b82e9 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -259,7 +259,7 @@ static u32 airtime_link_metric_get(struct ieee80211_local *local,
* @hwmp_ie: hwmp information element (PREP or PREQ)
*
* This function updates the path routing information to the originator and the
- * transmitter of a HWMP PREQ or PREP fram.
+ * transmitter of a HWMP PREQ or PREP frame.
*
* Returns: metric to frame originator or 0 if the frame should not be further
* processed
--
1.5.6.3
^ permalink raw reply related
* [PATCH] mesh: use set_bit() to set MESH_WORK_HOUSEKEEPING.
From: Rui Paulo @ 2009-10-20 20:21 UTC (permalink / raw)
To: linux-wireless; +Cc: javier, John Linville
This makes the mesh housekeeping timer work properly on big endian
systems.
Signed-off-by: Rui Paulo <rpaulo@gmail.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
net/mac80211/mesh.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index f7364e5..9a73389 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -50,7 +50,7 @@ static void ieee80211_mesh_housekeeping_timer(unsigned long data)
struct ieee80211_local *local = sdata->local;
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
- ifmsh->wrkq_flags |= MESH_WORK_HOUSEKEEPING;
+ set_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags);
if (local->quiescing) {
set_bit(TMR_RUNNING_HK, &ifmsh->timers_running);
@@ -480,7 +480,7 @@ void ieee80211_start_mesh(struct ieee80211_sub_if_data *sdata)
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
struct ieee80211_local *local = sdata->local;
- ifmsh->wrkq_flags |= MESH_WORK_HOUSEKEEPING;
+ set_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags);
ieee80211_queue_work(&local->hw, &ifmsh->work);
sdata->vif.bss_conf.beacon_int = MESH_DEFAULT_BEACON_INTERVAL;
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON |
--
1.6.4.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox