* [PATCH 13/16] iwmc3200wifi: Try shared auth when open WEP fails
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-13-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
When we fail to associate with an open WEP AP, we fall back to shared auth.
This allows us to support joining a shared auth WEP AP with iwconfig.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/commands.c | 2 +-
drivers/net/wireless/iwmc3200wifi/iwm.h | 1 +
drivers/net/wireless/iwmc3200wifi/main.c | 28 ++++++++++++++++++++++++++
drivers/net/wireless/iwmc3200wifi/rx.c | 28 +++++++++++++++++++++----
4 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/commands.c b/drivers/net/wireless/iwmc3200wifi/commands.c
index 2911ace..7e12438 100644
--- a/drivers/net/wireless/iwmc3200wifi/commands.c
+++ b/drivers/net/wireless/iwmc3200wifi/commands.c
@@ -794,7 +794,7 @@ int iwm_invalidate_mlme_profile(struct iwm_priv *iwm)
return ret;
ret = wait_event_interruptible_timeout(iwm->mlme_queue,
- (iwm->umac_profile_active == 0), 2 * HZ);
+ (iwm->umac_profile_active == 0), 5 * HZ);
return ret ? 0 : -EBUSY;
}
diff --git a/drivers/net/wireless/iwmc3200wifi/iwm.h b/drivers/net/wireless/iwmc3200wifi/iwm.h
index fe0ab80..c4a01f2 100644
--- a/drivers/net/wireless/iwmc3200wifi/iwm.h
+++ b/drivers/net/wireless/iwmc3200wifi/iwm.h
@@ -285,6 +285,7 @@ struct iwm_priv {
u8 *eeprom;
struct timer_list watchdog;
struct work_struct reset_worker;
+ struct work_struct auth_retry_worker;
struct mutex mutex;
u8 *req_ie;
diff --git a/drivers/net/wireless/iwmc3200wifi/main.c b/drivers/net/wireless/iwmc3200wifi/main.c
index dfc8fd4..97c6f5a 100644
--- a/drivers/net/wireless/iwmc3200wifi/main.c
+++ b/drivers/net/wireless/iwmc3200wifi/main.c
@@ -208,6 +208,33 @@ static void iwm_reset_worker(struct work_struct *work)
mutex_unlock(&iwm->mutex);
}
+static void iwm_auth_retry_worker(struct work_struct *work)
+{
+ struct iwm_priv *iwm;
+ int i, ret;
+
+ iwm = container_of(work, struct iwm_priv, auth_retry_worker);
+ if (iwm->umac_profile_active) {
+ ret = iwm_invalidate_mlme_profile(iwm);
+ if (ret < 0)
+ return;
+ }
+
+ iwm->umac_profile->sec.auth_type = UMAC_AUTH_TYPE_LEGACY_PSK;
+
+ ret = iwm_send_mlme_profile(iwm);
+ if (ret < 0)
+ return;
+
+ for (i = 0; i < IWM_NUM_KEYS; i++)
+ if (iwm->keys[i].key_len)
+ iwm_set_key(iwm, 0, &iwm->keys[i]);
+
+ iwm_set_tx_key(iwm, iwm->default_key);
+}
+
+
+
static void iwm_watchdog(unsigned long data)
{
struct iwm_priv *iwm = (struct iwm_priv *)data;
@@ -241,6 +268,7 @@ int iwm_priv_init(struct iwm_priv *iwm)
INIT_DELAYED_WORK(&iwm->disconnect, iwm_disconnect_work);
INIT_DELAYED_WORK(&iwm->ct_kill_delay, iwm_ct_kill_work);
INIT_WORK(&iwm->reset_worker, iwm_reset_worker);
+ INIT_WORK(&iwm->auth_retry_worker, iwm_auth_retry_worker);
INIT_LIST_HEAD(&iwm->bss_list);
skb_queue_head_init(&iwm->rx_list);
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 0fa3f5c..c0fa853 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -502,6 +502,18 @@ static int iwm_mlme_assoc_start(struct iwm_priv *iwm, u8 *buf,
return 0;
}
+static u8 iwm_is_open_wep_profile(struct iwm_priv *iwm)
+{
+ if ((iwm->umac_profile->sec.ucast_cipher == UMAC_CIPHER_TYPE_WEP_40 ||
+ iwm->umac_profile->sec.ucast_cipher == UMAC_CIPHER_TYPE_WEP_104) &&
+ (iwm->umac_profile->sec.ucast_cipher ==
+ iwm->umac_profile->sec.mcast_cipher) &&
+ (iwm->umac_profile->sec.auth_type == UMAC_AUTH_TYPE_OPEN))
+ return 1;
+
+ return 0;
+}
+
static int iwm_mlme_assoc_complete(struct iwm_priv *iwm, u8 *buf,
unsigned long buf_size,
struct iwm_wifi_cmd *cmd)
@@ -567,11 +579,17 @@ static int iwm_mlme_assoc_complete(struct iwm_priv *iwm, u8 *buf,
goto ibss;
if (!test_bit(IWM_STATUS_RESETTING, &iwm->status))
- cfg80211_connect_result(iwm_to_ndev(iwm),
- complete->bssid,
- NULL, 0, NULL, 0,
- WLAN_STATUS_UNSPECIFIED_FAILURE,
- GFP_KERNEL);
+ if (!iwm_is_open_wep_profile(iwm)) {
+ cfg80211_connect_result(iwm_to_ndev(iwm),
+ complete->bssid,
+ NULL, 0, NULL, 0,
+ WLAN_STATUS_UNSPECIFIED_FAILURE,
+ GFP_KERNEL);
+ } else {
+ /* Let's try shared WEP auth */
+ IWM_ERR(iwm, "Trying WEP shared auth\n");
+ schedule_work(&iwm->auth_retry_worker);
+ }
else
cfg80211_disconnected(iwm_to_ndev(iwm), 0, NULL, 0,
GFP_KERNEL);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 14/16] iwmc3200wifi: Support unexpected reboot barker
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-14-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
We can receive unexpected reboot barker at any time, and we're supposed to
reset the whole device then.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index c0fa853..95deb0a 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -1322,6 +1322,14 @@ int iwm_rx_handle(struct iwm_priv *iwm, u8 *buf, unsigned long buf_size)
switch (le32_to_cpu(hdr->cmd)) {
case UMAC_REBOOT_BARKER:
+ if (test_bit(IWM_STATUS_READY, &iwm->status)) {
+ IWM_ERR(iwm, "Unexpected BARKER\n");
+
+ schedule_work(&iwm->reset_worker);
+
+ return 0;
+ }
+
return iwm_notif_send(iwm, NULL, IWM_BARKER_REBOOT_NOTIFICATION,
IWM_SRC_UDMA, buf, buf_size);
case UMAC_ACK_BARKER:
--
1.6.0.4
^ permalink raw reply related
* [PATCH 15/16] iwmc3200wifi: Set wiphy firmware version
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-15-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
Our wiphy firmware version is a combination of the UMAC and LMAC ones.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/fw.c | 7 +++++++
drivers/net/wireless/iwmc3200wifi/iwm.h | 2 ++
drivers/net/wireless/iwmc3200wifi/main.c | 4 ++++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/fw.c b/drivers/net/wireless/iwmc3200wifi/fw.c
index f02d571..4906709 100644
--- a/drivers/net/wireless/iwmc3200wifi/fw.c
+++ b/drivers/net/wireless/iwmc3200wifi/fw.c
@@ -217,6 +217,13 @@ static int iwm_load_img(struct iwm_priv *iwm, const char *img_name)
IWM_BUILD_YEAR(build_date), IWM_BUILD_MONTH(build_date),
IWM_BUILD_DAY(build_date));
+ if (!strcmp(img_name, iwm->bus_ops->umac_name))
+ sprintf(iwm->umac_version, "%02X.%02X",
+ ver->major, ver->minor);
+
+ if (!strcmp(img_name, iwm->bus_ops->lmac_name))
+ sprintf(iwm->lmac_version, "%02X.%02X",
+ ver->major, ver->minor);
err_release_fw:
release_firmware(fw);
diff --git a/drivers/net/wireless/iwmc3200wifi/iwm.h b/drivers/net/wireless/iwmc3200wifi/iwm.h
index c4a01f2..a9bf6bc 100644
--- a/drivers/net/wireless/iwmc3200wifi/iwm.h
+++ b/drivers/net/wireless/iwmc3200wifi/iwm.h
@@ -294,6 +294,8 @@ struct iwm_priv {
int resp_ie_len;
struct iwm_fw_error_hdr *last_fw_err;
+ char umac_version[8];
+ char lmac_version[8];
char private[0] __attribute__((__aligned__(NETDEV_ALIGN)));
};
diff --git a/drivers/net/wireless/iwmc3200wifi/main.c b/drivers/net/wireless/iwmc3200wifi/main.c
index 97c6f5a..75f105a 100644
--- a/drivers/net/wireless/iwmc3200wifi/main.c
+++ b/drivers/net/wireless/iwmc3200wifi/main.c
@@ -629,6 +629,7 @@ static int __iwm_up(struct iwm_priv *iwm)
{
int ret;
struct iwm_notif *notif_reboot, *notif_ack = NULL;
+ struct wiphy *wiphy = iwm_to_wiphy(iwm);
ret = iwm_bus_enable(iwm);
if (ret) {
@@ -690,6 +691,9 @@ static int __iwm_up(struct iwm_priv *iwm)
goto err_disable;
}
+ snprintf(wiphy->fw_version, sizeof(wiphy->fw_version), "L%s_U%s",
+ iwm->lmac_version, iwm->umac_version);
+
/* We configure the UMAC and enable the wifi module */
ret = iwm_send_umac_config(iwm,
cpu_to_le32(UMAC_RST_CTRL_FLG_WIFI_CORE_EN) |
--
1.6.0.4
^ permalink raw reply related
* [PATCH 16/16] iwmc3200wifi: handle coexistence radio notification
From: Zhu Yi @ 2009-10-16 5:19 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
In-Reply-To: <1255670340-22565-16-git-send-email-yi.zhu@intel.com>
Handle WiFi/WiMax coexistence radio preemption notification event.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 95deb0a..bdb1d7e 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -733,6 +733,19 @@ static int iwm_mlme_update_sta_table(struct iwm_priv *iwm, u8 *buf,
return 0;
}
+static int iwm_mlme_medium_lost(struct iwm_priv *iwm, u8 *buf,
+ unsigned long buf_size,
+ struct iwm_wifi_cmd *cmd)
+{
+ struct wiphy *wiphy = iwm_to_wiphy(iwm);
+
+ IWM_DBG_NTF(iwm, DBG, "WiFi/WiMax coexistence radio is OFF\n");
+
+ wiphy_rfkill_set_hw_state(wiphy, true);
+
+ return 0;
+}
+
static int iwm_mlme_update_bss_table(struct iwm_priv *iwm, u8 *buf,
unsigned long buf_size,
struct iwm_wifi_cmd *cmd)
@@ -919,6 +932,8 @@ static int iwm_ntf_mlme(struct iwm_priv *iwm, u8 *buf,
case WIFI_IF_NTFY_EXTENDED_IE_REQUIRED:
IWM_DBG_MLME(iwm, DBG, "Extended IE required\n");
break;
+ case WIFI_IF_NTFY_RADIO_PREEMPTION:
+ return iwm_mlme_medium_lost(iwm, buf, buf_size, cmd);
case WIFI_IF_NTFY_BSS_TRK_TABLE_CHANGED:
return iwm_mlme_update_bss_table(iwm, buf, buf_size, cmd);
case WIFI_IF_NTFY_BSS_TRK_ENTRIES_REMOVED:
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 1/1] staging/stlc45xx: Fix compile error
From: Kalle Valo @ 2009-10-16 7:13 UTC (permalink / raw)
To: Greg KH
Cc: Javier Martinez Canillas, devel@driverdev.osuosl.org,
linux-wireless
In-Reply-To: <20091015031138.GB16633@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Wed, Oct 14, 2009 at 11:03:45PM -0400, Javier Martinez Canillas wrote:
>> I got the following compile error with today linux-next tree.
>>
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_reset’:
>> drivers/staging/stlc45xx/stlc45xx.c:1061: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_interrupt’:
>> drivers/staging/stlc45xx/stlc45xx.c:1492: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_wq_tx’:
>> drivers/staging/stlc45xx/stlc45xx.c:1571: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_op_tx’:
>> drivers/staging/stlc45xx/stlc45xx.c:2135: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: At top level:
>> drivers/staging/stlc45xx/stlc45xx.c:2351: warning: initialization from incompatible pointer type
>>
>> The driver was trying to access directly to mac80211 workqueue. Use the helper functions instead.
>>
>> I think this patch solves the issue. Also fix a compile warning due a change in configure_filter() handler params.
>
> ah, good catch, I had that driver disabled in my builds for some stupid
> reason. I'll queue this up in my tree.
I think it's better to drop stlc45xx. As I haven't sent any patches for
few months is obvious that I don't have time to work on it anymore. And
p54spi should work now, at least I have seen positive reports on mailing
lists.
Greg, if you want I can send a patch removing stlc45xx.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] wl1251: add support for PG11 chips.
From: Kalle Valo @ 2009-10-16 7:19 UTC (permalink / raw)
To: John Willis; +Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <01c201ca4d9c$c2c44500$484ccf00$@Willis@Distant-earth.com>
John Willis <John.Willis@Distant-earth.com> writes:
> From: David-John Willis <John.Willis@Distant-earth.com>
>
> This simple patch adds support for the PG11 variant of the WL1251 chip as
> used on the OpenPandora OMAP3 device.
>
> Signed-off-by: David-John Willis <John.Willis@Distant-earth.com>
Thanks for the patch. And excellent news that it's working on your
device.
Minor comment:
> --- a/drivers/net/wireless/wl12xx/wl1251_main.c
> +++ b/drivers/net/wireless/wl12xx/wl1251_main.c
> @@ -185,6 +185,9 @@ static int wl1251_chip_wakeup(struct wl1251 *wl)
> break;
> case CHIP_ID_1251_PG10:
> case CHIP_ID_1251_PG11:
> + wl1251_debug(DEBUG_BOOT, "chip id 0x%x (1251 PG11)",
> + wl->chip_id);
> + break;
> default:
> wl1251_error("unsupported chip id: 0x%x", wl->chip_id);
> ret = -ENODEV;
This patch also enables PG10 support, but as that hardware revision is
untested I think it's better not to enable it. I'll edit the patch a bit
regarding this and then send it to John.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver
From: Kalle Valo @ 2009-10-16 7:52 UTC (permalink / raw)
To: John Willis; +Cc: me, linux-wireless
In-Reply-To: <01c901ca4daf$6e3d7f20$4ab87d60$@Willis@Distant-earth.com>
"John Willis" <John.Willis@Distant-earth.com> writes:
> Gents,
>
> Attached are some very hacky (even after a quick cleanup) patches that add
> something like support for reading the EEPROM NVS calibration data into the
> WL1251 driver. It seems just good enough to get the driver up and playing
> nicely.
Thanks a lot, this is good stuff. Now we have all hardware
configurations (known by me) supported in wl1251: SPI, SDIO, without
EEPROM and with EEPROM.
> I quickly rebased the patches on the top of wireless-testing, with any luck
> they still work however I can't test as there is something badly borked for
> OMAP3 in the mainline tree feeding WT at the moment. I have left out a lot
> of my development chaff and rubbish from the patches.
In cases like this I usually merge linux-omap to wireless-testing,
it's quite simple and fast thing to do. That way I get the omap
hardware booting with latest wireless stuff.
> They have only been tested on OMAP3 OpenPandora boards using SDIO. I still
> think timing needs tweaking but I have not had a chance to look into that.
I have few comments about the patch. I think it's better to configure
EEPROM support runtime and not via Kconfig. Also I don't like
hungarian notation :)
Is it okay if I clean it up a bit and then send it to John Linville?
Better to have the patch in the tree as early as possible, as long as it
doesn't break existing functionality. We can always fix it later if
there's something broken.
Thanks again for your patches and please keep on sending them :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] wl1251: add support for PG11 chips.
From: Kalle Valo @ 2009-10-16 8:37 UTC (permalink / raw)
To: John Willis; +Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <87vdifbyao.fsf@nokia.com>
Kalle Valo <kalle.valo@iki.fi> writes:
> John Willis <John.Willis@Distant-earth.com> writes:
>
>> From: David-John Willis <John.Willis@Distant-earth.com>
>>
>> This simple patch adds support for the PG11 variant of the WL1251 chip as
>> used on the OpenPandora OMAP3 device.
>>
>> Signed-off-by: David-John Willis <John.Willis@Distant-earth.com>
[...]
> This patch also enables PG10 support, but as that hardware revision is
> untested I think it's better not to enable it. I'll edit the patch a bit
> regarding this and then send it to John.
Oh, I noticed that Linville had already applied your patch. I'll send
a patch on top of this to fix the issue.
Linville, is this ok for you?
Too many Johns here :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Simon Raffeiner @ 2009-10-16 9:49 UTC (permalink / raw)
To: users, linux-wireless
In-Reply-To: <200910152204.16407.IvDoorn@gmail.com>
Hello List,
I was comparing rt2800pci and the INF file of the original RT2860 windows
driver out curiosity. The original INF file contains 108 PCI id entries,
rt2800pci.c only 20. At first I thought that an entry like
PCI\VEN_1814&DEV_0601&SUBSYS_77281432
(Edimax card) in the INF file will be automatically matched by rt2800pci for
the "1814:0601" vendor/device id, but then I found an additional entry for
"1432:7728" (the susbsystem id) in the rt2800pci pci_device_id table.
I am a bit confused: Should every entry from the INF file have a PCI_DEVICE()
counterpart in our driver (resulting in 108 entries), or is this a special
case where the Manufacturer (Edimax) produces cards that actually have
"1432:7728" as vendor/device id.
You can probably tell that I don't have much experience developing kernel
drivers, but I am willing to get it right.
regards,
Simon Raffeiner
Am Donnerstag, 15. Oktober 2009 22:04:14 schrieb Ivo van Doorn:
> Add support for the rt2860/rt3090 chipsets from Ralink.
>
> Includes various patches from a lot of people who helped
> getting this driver into the current shape.
>
> Signed-off-by: Alban Browaeys <prahal@yahoo.com>
> Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Luis Correia <luis.f.correia@gmail.com>
> Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
> Signed-off-by: Mark Asselstine <asselsm@gmail.com>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> http://kernel.org/pub/linux/kernel/people/ivd/patches/0003-rt2x00-Implement
> -support-for-rt2800pci.patch --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 7/8] trivial: fix many typos s/untill/until/
From: Ivo van Doorn @ 2009-10-16 10:04 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: trivial, linux-rdma, linux-kernel, bonding-devel, netdev,
linux-wireless, users, linux-scsi, devel, linux-ext4,
linux-bluetooth, linux-sctp
In-Reply-To: <1255638072-6236-1-git-send-email-cascardo@holoscopio.com>
On Thursday 15 October 2009, Thadeu Lima de Souza Cascardo wrote:
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
For rt2800usb
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/infiniband/ulp/iser/iser_verbs.c | 2 +-
> drivers/net/bonding/bond_alb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
> drivers/scsi/bnx2i/bnx2i_iscsi.c | 2 +-
> drivers/staging/rtl8187se/r8180.h | 2 +-
> fs/ext4/balloc.c | 2 +-
> net/bluetooth/bnep/core.c | 2 +-
> net/sctp/sm_statefuns.c | 2 +-
> 8 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/iser/iser_verbs.c b/drivers/infiniband/ulp/iser/iser_verbs.c
> index ea9e155..8579f32 100644
> --- a/drivers/infiniband/ulp/iser/iser_verbs.c
> +++ b/drivers/infiniband/ulp/iser/iser_verbs.c
> @@ -499,7 +499,7 @@ void iser_conn_init(struct iser_conn *ib_conn)
>
> /**
> * starts the process of connecting to the target
> - * sleeps untill the connection is established or rejected
> + * sleeps until the connection is established or rejected
> */
> int iser_connect(struct iser_conn *ib_conn,
> struct sockaddr_in *src_addr,
> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
> index 9b5936f..a1e7eb9 100644
> --- a/drivers/net/bonding/bond_alb.c
> +++ b/drivers/net/bonding/bond_alb.c
> @@ -559,7 +559,7 @@ static void rlb_update_rx_clients(struct bonding *bond)
> }
> }
>
> - /* do not update the entries again untill this counter is zero so that
> + /* do not update the entries again until this counter is zero so that
> * not to confuse the clients.
> */
> bond_info->rlb_update_delay_counter = RLB_UPDATE_DELAY;
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index a084077..449886c 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -1257,7 +1257,7 @@ static int rt2800usb_init_registers(struct rt2x00_dev *rt2x00dev)
> unsigned int i;
>
> /*
> - * Wait untill BBP and RF are ready.
> + * Wait until BBP and RF are ready.
> */
> for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
> rt2x00usb_register_read(rt2x00dev, MAC_CSR0, ®);
> diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
> index cafb888..10110be 100644
> --- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
> +++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
> @@ -1883,7 +1883,7 @@ static void bnx2i_ep_disconnect(struct iscsi_endpoint *ep)
>
> bnx2i_ep = ep->dd_data;
>
> - /* driver should not attempt connection cleanup untill TCP_CONNECT
> + /* driver should not attempt connection cleanup until TCP_CONNECT
> * completes either successfully or fails. Timeout is 9-secs, so
> * wait for it to complete
> */
> diff --git a/drivers/staging/rtl8187se/r8180.h b/drivers/staging/rtl8187se/r8180.h
> index 8216d7e..35ed60b 100644
> --- a/drivers/staging/rtl8187se/r8180.h
> +++ b/drivers/staging/rtl8187se/r8180.h
> @@ -521,7 +521,7 @@ typedef struct r8180_priv
> //u32 NumTxOkInPeriod; //YJ,del,080828
> u8 TxPollingTimes;
>
> - bool bApBufOurFrame;// TRUE if AP buffer our unicast data , we will keep eAwake untill receive data or timeout.
> + bool bApBufOurFrame;// TRUE if AP buffer our unicast data , we will keep eAwake until receive data or timeout.
> u8 WaitBufDataBcnCount;
> u8 WaitBufDataTimeOut;
>
> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index 1d04189..2565b8c 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -519,7 +519,7 @@ void ext4_free_blocks(handle_t *handle, struct inode *inode,
> metadata = 1;
>
> /* We need to make sure we don't reuse
> - * block released untill the transaction commit.
> + * block released until the transaction commit.
> * writeback mode have weak data consistency so
> * don't force data as metadata when freeing block
> * for writeback mode.
> diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
> index 1bd9398..9ac0497 100644
> --- a/net/bluetooth/bnep/core.c
> +++ b/net/bluetooth/bnep/core.c
> @@ -629,7 +629,7 @@ int bnep_del_connection(struct bnep_conndel_req *req)
> s = __bnep_get_session(req->dst);
> if (s) {
> /* Wakeup user-space which is polling for socket errors.
> - * This is temporary hack untill we have shutdown in L2CAP */
> + * This is temporary hack until we have shutdown in L2CAP */
> s->sock->sk->sk_err = EUNATCH;
>
> /* Kill session thread */
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index c8fae19..ba2f66d 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -3569,7 +3569,7 @@ sctp_disposition_t sctp_sf_do_asconf(const struct sctp_endpoint *ep,
> * To do this properly, we'll set the destination address of the chunk
> * and at the transmit time, will try look up the transport to use.
> * Since ASCONFs may be bundled, the correct transport may not be
> - * created untill we process the entire packet, thus this workaround.
> + * created until we process the entire packet, thus this workaround.
> */
> asconf_ack->dest = chunk->source;
> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(asconf_ack));
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Ivo van Doorn @ 2009-10-16 10:55 UTC (permalink / raw)
To: users; +Cc: Simon Raffeiner, linux-wireless, Xose Vazquez Perez
In-Reply-To: <200910161149.11661.sturmflut@lieberbiber.de>
Hi,
> I was comparing rt2800pci and the INF file of the original RT2860 windows
> driver out curiosity. The original INF file contains 108 PCI id entries,
> rt2800pci.c only 20. At first I thought that an entry like
>
> PCI\VEN_1814&DEV_0601&SUBSYS_77281432
>
> (Edimax card) in the INF file will be automatically matched by rt2800pci for
> the "1814:0601" vendor/device id, but then I found an additional entry for
> "1432:7728" (the susbsystem id) in the rt2800pci pci_device_id table.
>
> I am a bit confused: Should every entry from the INF file have a PCI_DEVICE()
> counterpart in our driver (resulting in 108 entries), or is this a special
> case where the Manufacturer (Edimax) produces cards that actually have
> "1432:7728" as vendor/device id.
>
> You can probably tell that I don't have much experience developing kernel
> drivers, but I am willing to get it right.
Well the main PCI and DEVICE id's should be listed in the PCI_DEVICE table,
the SUBSYS ID should only be added in case there can be different drivers
based on that ID.
As far as the ID 1432:7728, that one was send by Xose who got the ID from
the Windows driver, I don't know if he has mistakenly grabbed the subsystem ID or not...
Xose, could you give an update about this?
Ivo
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Xose Vazquez Perez @ 2009-10-16 11:12 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: users, Simon Raffeiner, linux-wireless
In-Reply-To: <200910161255.54644.IvDoorn@gmail.com>
On Fri, Oct 16, 2009 at 12:55, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> Well the main PCI and DEVICE id's should be listed in the PCI_DEVICE table,
> the SUBSYS ID should only be added in case there can be different drivers
> based on that ID.
>
> As far as the ID 1432:7728, that one was send by Xose who got the ID from
> the Windows driver, I don't know if he has mistakenly grabbed the subsystem ID or not...
> Xose, could you give an update about this?
It came from ralink linux driver.
See 2009_0918_RT2860_Linux_STA_v2.2.0.0/os/linux/pci_main_dev.c:
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2860_PCI_DEVICE_ID)},
//RT28602.4G
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2860_PCIe_DEVICE_ID)},
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2760_PCI_DEVICE_ID)},
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2790_PCIe_DEVICE_ID)},
{PCI_DEVICE(VEN_AWT_PCI_VENDOR_ID, VEN_AWT_PCIe_DEVICE_ID)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7708)},
->>>>> {PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7728)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7758)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7727)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7738)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7748)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7768)},
regards,
--
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»
^ permalink raw reply
* Re: [PATCH] mac80211: fix SME warning by removing stale BSS upon assoc failure
From: Johannes Berg @ 2009-10-16 9:31 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ic.felix@gmail.com
In-Reply-To: <20091014233528.GA4172@tux>
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
On Wed, 2009-10-14 at 16:35 -0700, Luis R. Rodriguez wrote:
> Well sure, but why do we want to keep the authentication present if
> association failed? And as a matter of fact it lingers there forever.
> Is that desired behaviour?
Yes, well, the SME is supposed to clean it up or try the association
again (possibly with different parameters in the IEs, e.g. different WPA
settings). The cfg80211 SME certainly does so (it deauthenticates).
> > > +++ b/net/mac80211/mlme.c
> > > @@ -1463,11 +1463,11 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
> > > if (status_code != WLAN_STATUS_SUCCESS) {
> > > printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
> > > sdata->dev->name, status_code);
> > > list_del(&wk->list);
> > > kfree(wk);
> > > - return RX_MGMT_CFG80211_ASSOC;
> > > + return RX_MGMT_CFG80211_DEAUTH;
> >
> > I'm sure this is correct. Maybe cfg80211 doesn't react properly to
> > getting an assoc frame with non-zero status?
>
> I see, will have to take a look when I get a chance then, not now though.
> Actually can you elaborate a little on the logic here as to why
> we want to issue an association command with non-zero status to
> cfg80211 instead of just knocking off the current authentication
> and killing the BSS?
Is the above sufficient? Btw, please don't talk about "killing the BSS",
you're not talking about a BSS struct but rather one of the mlme work
structs.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: remove warning in deauth case
From: Johannes Berg @ 2009-10-16 9:32 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John W. Linville
In-Reply-To: <200910131345.28395.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
On Tue, 2009-10-13 at 13:45 +0200, Holger Schurig wrote:
> It might be the case that __cfg80211_disconnected() has already
> cleaned up wdev->current_bss() for us. The old code didn't catch
> that situation and didn't warn needlessly.
Care to explain how that can happen?
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
>
> ---
>
> For more info, see mail "cfg80211 / libertas: an unusual race"
> in the linux-wireless mailing list.
Oh ok, I suppose that explains it?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.32-rc4-git1 -- INFO: possible circular locking dependency detected
From: Johannes Berg @ 2009-10-16 9:34 UTC (permalink / raw)
To: Miles Lane; +Cc: LKML, linux-wireless
In-Reply-To: <a44ae5cd0910120528h6d8992fcn8b6592ee799fbfc5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Mon, 2009-10-12 at 08:28 -0400, Miles Lane wrote:
> [ 823.466853] [ INFO: possible circular locking dependency detected ]
> [ 823.466866] 2.6.32-rc4-git1 #2
> [ 823.466873] -------------------------------------------------------
> [ 823.466884] swapper/0 is trying to acquire lock:
> [ 823.466893] (&sta->lock){+.-...}, at: [<f857bda4>] sta_addba_resp_timer_expired+0x1b/0x50 [mac80211]
> [ 823.466940]
> [ 823.466943] but task is already holding lock:
> [ 823.466953] (&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer){+.-...}, at: [<c1032f22>] run_timer_softirq+0x125/0x1e5
> [ 823.466984]
> [ 823.466987] which lock already depends on the new lock.
Thanks for the report, I'll have to take a look at it, but this appears
to be due to the del_timer_sync() in ieee80211_process_addba_resp().
Guess it never really happens that the AP doesn't respond quickly enough
so the timer hardly fires.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: deauthentication and disassociation nl80211 commands
From: Johannes Berg @ 2009-10-16 9:36 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Maxim Levitsky, hostap@lists.shmoo.com, linux-wireless
In-Reply-To: <20091012065507.GB25578@jm.kir.nu>
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
On Mon, 2009-10-12 at 09:55 +0300, Jouni Malinen wrote:
> On Sat, Oct 10, 2009 at 06:24:26PM +0200, Johannes Berg wrote:
> > On the other hand, I think Jouni's argument is that you should be able
> > to authenticate (force an auth frame exchange) even while authenticated.
> > I don't really disagree with that all that much, but I'm not sure how to
> > cleanly fit it in. mac80211 would have to reset the auth state without
> > sending a deauth.
>
> Yes, this is exactly what I would like to see happening when using
> mac80211. For now, I think we can work around the issue in
> wpa_supplicant, but eventually, this change in mac80211 would allow the
> code in wpa_supplicant to be cleaned up and the need for an extra
> deauthentication frame could be removed.
This would require a change in cfg80211 too, since that keeps the BSS
list around and refuses this, mac80211 isn't necessarily involved.
However, we need to spec it out more clearly. For instance, we'd have to
not add a new work item and try for another authentication, but rather
use the old one. Right?
I'm happy to have such a change, but it needs to be clearly documented
what is expected of drivers that get an auth() call while already
authenticated with that AP. Especially since it's not just
send_auth_frame(), as we expect the driver to handle the entire
handshake for WEP SK auth.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [WIP, RFC] libertas: allow scanning via "iw"
From: Johannes Berg @ 2009-10-16 9:50 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910141652.11203.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
On Wed, 2009-10-14 at 16:52 +0200, Holger Schurig wrote:
> Do not apply, but please look at the code and comment harshly :-)
>
> +#ifdef TODO
> /* Scan results list */
> struct list_head network_list;
> struct list_head network_free_list;
> struct bss_descriptor *networks;
> +#endif
It'd be easier to read and see what the patch does if you actually
removed all the stuff that is no longer necessary :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wl1251: rename spi device to wl1251
From: Johannes Berg @ 2009-10-16 9:51 UTC (permalink / raw)
To: Kalle Valo; +Cc: linville, linux-wireless
In-Reply-To: <20091013174119.15796.81021.stgit@tikku>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On Tue, 2009-10-13 at 20:41 +0300, Kalle Valo wrote:
> -MODULE_ALIAS("spi:wl12xx");
> +MODULE_ALIAS("spi:wl1251");
> diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c b/drivers/net/wireless/wl12xx/wl1251_spi.c
> index 14eff2b..2cf8a21 100644
> --- a/drivers/net/wireless/wl12xx/wl1251_spi.c
> +++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
> @@ -307,7 +307,7 @@ static int __devexit wl1251_spi_remove(struct spi_device *spi)
>
> static struct spi_driver wl1251_spi_driver = {
> .driver = {
> - .name = "wl12xx",
> + .name = "wl1251",
> .bus = &spi_bus_type,
> .owner = THIS_MODULE,
IIRC there's a preprocessor symbol for the module name (MODULE_NAME?)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: cfg80211 / libertas: an unusual race
From: Johannes Berg @ 2009-10-16 9:57 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910131055.31739.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On Tue, 2009-10-13 at 10:55 +0200, Holger Schurig wrote:
> But at step "3. b)", which now happens at a later time,
> wdev_current_bss is no longer set. This triggers a
> WARN_ON(!done) warning in __cfg80211_send_deauth(),
> file net/wireless/mlme.c
>
> Would it be O.K. to simply remove the WARN_ON(!done) ?
> After all, wdev>current_bss was put'ted and cleared correctly.
I don't see this happening that way -- how are you even getting to
__cfg80211_disconnected() if not through _send_deauth()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: BUG? I can reproduce "Association request to the driver failed" at will
From: Johannes Berg @ 2009-10-16 10:07 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Holger Schurig, linux-wireless, hostap
In-Reply-To: <20091012071550.GD25578@jm.kir.nu>
[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]
On Mon, 2009-10-12 at 10:15 +0300, Jouni Malinen wrote:
> Though, even in this case, there is actually a bug somewhere (in
> mac80211, I would assume).. The authentication attempt with the second
> AP times out because mac80211 ends up sending the direct probes to the
> MAC address of the old AP (which is now turned off). When wpa_supplicant
> tries to authenticate again, the direct probes are going to the correct
> destination and connection can be established.
I can't see that happen in mac80211 -- can somebody run this with some
printks in cfg80211 that tell us what exactly is being passed down to
mac80211's auth() call?
> I can reproduce this with the current wpa_supplicant (that has a
> workaround for this EALREADY for authentication case, but not for
> assoc) and the current wireless-testing. Roaming will get mac80211 into
> very odd state..
>
> Not only is this association failing (after the authentication with the
> same AP actually worked), but the scanning state will also get quite
> confused.. The next scan trigger after this is never completed (iw scan
> gets stuck). Or well, actually, once I wait long enough for the AP to
> deauthenticate the client, it looks like mac80211 can recover. The scan
> command returned after five minutes of waiting.. ;-)
Good hint. It looks like it gets stuck between assoc and auth for the
old AP?
> > The "Association request to the driver failed" will
> > be shown even without "-d". Also note that the association
> > seems to actually work, e.g. I can ping throught the
> > connection.
>
> mac80211 remains associated with the old AP (I think) and somehow
> remains in the state between authentication and association (with the
> new AP) which will block scans.
I think we need a cfg80211 event tracer :)
Actually, does wpa_supplicant _deauth_ from the AP, or does it just
disassoc? It's definitely supposed to deauth.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: SME warning on 2.6.32-rc<bleh>
From: Johannes Berg @ 2009-10-16 10:09 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890909291224t26b7e6cbmc78976165bd1bb88@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
On Tue, 2009-09-29 at 12:24 -0700, Luis R. Rodriguez wrote:
> I believe the problem comes from the assumption from cfg80211 that
> previous deauthentications would have gone through before we run
> __cfg80211_disconnected() and are using wext or nl80211
> connec/disconnectt. Under certain conditions (clearly not known yet)
> this is not true and we'll end up asking mac80211 to deauthenticate us
> from a BSS we already deauthenticated to end end up with an -ENOLINK
> on our mac80211 cfg80211 deauth ops. It seems this race was expected
> all along on mac80211 ieee80211_mgd_deauth():
>
> /*
> * cfg80211 should catch this ... but it's racy since
> * we can receive a deauth frame, process it, hand it
> * to cfg80211 while that's in a locked section already
> * trying to tell us that the user wants to disconnect.
> */
> if (!bssid) {
> mutex_unlock(&ifmgd->mtx);
> return -ENOLINK;
> }
>
> So it seems we do need to address that race but I'm not yet sure how.
I don't think so. The race is definitely there in mac80211, but not in
cfg80211, since both processing the deauth frame and sending a deauth
frame in cfg80211 are both under the same lock.
OTOH, it could happen with lock contention, but that seems very unlikely
here?
I mean -- this race should only happen if the AP and you decide to
deauth at the /same/ time. Precisely the same time.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: BUG: can bring wpa_supplicant/mac80211 into a stuck state at will
From: Johannes Berg @ 2009-10-16 10:11 UTC (permalink / raw)
To: Holger Schurig; +Cc: hostap, linux-wireless, Jouni Malinen
In-Reply-To: <1253776815.3868.10.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
On Thu, 2009-09-24 at 09:20 +0200, Johannes Berg wrote:
> On Mon, 2009-09-21 at 17:22 +0200, Holger Schurig wrote:
>
> > iw eth1 link
> > Connected to 00:1b:53:11:dc:40 (on eth1)
> > SSID: MNFUNK
> > freq: 2412
> > Authenticated with 00:13:19:80:da:30 (on eth1)
> > RX: 78173 bytes (722 packets)
> > TX: 144 bytes (4 packets)
> > signal: -67 dBm
> > tx bitrate: 11.0 MBit/s
>
> This is very odd, I'll look into it.
Actually, it's not odd. It looks like wpa_supplicant never
deauthenticated, since :30 was the AP you connected to _first_.
I suspect it'll all work better if you make wpa_supplicant deauth
instead of disassoc.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.32-rc4-git1 -- INFO: possible circular locking dependency detected
From: Johannes Berg @ 2009-10-16 10:20 UTC (permalink / raw)
To: Miles Lane; +Cc: LKML, linux-wireless
In-Reply-To: <a44ae5cd0910120528h6d8992fcn8b6592ee799fbfc5@mail.gmail.com>
Actually ... seems to be easy to fix.
Can you reproduce this reliably? I suspect not. If you can, try the
patch below to make sure -- I'm pretty certain it is a correct patch
anyhow though.
johannes
---
net/mac80211/agg-tx.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- wireless-testing.orig/net/mac80211/agg-tx.c 2009-10-16 19:13:48.000000000 +0900
+++ wireless-testing/net/mac80211/agg-tx.c 2009-10-16 19:15:12.000000000 +0900
@@ -666,11 +666,13 @@ void ieee80211_process_addba_resp(struct
state = &sta->ampdu_mlme.tid_state_tx[tid];
+ del_timer_sync(&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer);
+
spin_lock_bh(&sta->lock);
if (!(*state & HT_ADDBA_REQUESTED_MSK)) {
spin_unlock_bh(&sta->lock);
- return;
+ goto timer_still_needed;
}
if (mgmt->u.action.u.addba_resp.dialog_token !=
@@ -679,13 +681,13 @@ void ieee80211_process_addba_resp(struct
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "wrong addBA response token, tid %d\n", tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
- return;
+ goto timer_still_needed;
}
- del_timer_sync(&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer);
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "switched off addBA timer for tid %d \n", tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
+
if (le16_to_cpu(mgmt->u.action.u.addba_resp.status)
== WLAN_STATUS_SUCCESS) {
u8 curstate = *state;
@@ -700,4 +702,8 @@ void ieee80211_process_addba_resp(struct
___ieee80211_stop_tx_ba_session(sta, tid, WLAN_BACK_INITIATOR);
}
spin_unlock_bh(&sta->lock);
+
+ return;
+ timer_still_needed:
+ add_timer(&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer);
}
^ permalink raw reply
* Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver
From: Bob Copeland @ 2009-10-16 11:59 UTC (permalink / raw)
To: John Willis; +Cc: kalle.valo, linux-wireless
In-Reply-To: <01c901ca4daf$6e3d7f20$4ab87d60$@Willis@Distant-earth.com>
On Thu, Oct 15, 2009 at 04:51:49PM +0100, John Willis wrote:
> The patches are not yet complete but they do work for me (tm) so I would be
> very interested in seeing if these hacks also allow us to use the EEPROM on
> the HTC Dream (Bob, can you try that?, no rush however).
Yeah, I'll give it a spin. It'd be really nice if people don't need to
use the NVS file. Do you know the structure of the EEPROM data?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: cfg80211 / libertas: an unusual race
From: Holger Schurig @ 2009-10-16 12:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1255687030.4095.327.camel@johannes.local>
> I don't see this happening that way -- how are you even getting
to
> __cfg80211_disconnected() if not through _send_deauth()?
See step 7a in the second table. We got there via
_send_deauth().
But later, step 3b in the second table (I kept the original
numbers, so 3b happens after 7a time-wise!) we got into
WARN_ON().
--
http://www.holgerschurig.de
^ permalink raw reply
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