* [PATCH 14/14 v2] MAINTAINERS: Update ipw2x00 and iwlwifi entries
From: reinette chatre @ 2009-08-21 21:03 UTC (permalink / raw)
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org, James Ketrenos, Joe Perches
In-Reply-To: <1250888170.29546.106.camel@Joe-Laptop.home>
From: Reinette Chatre <reinette.chatre@intel.com>
Update MAINTAINERS file to reflect current maintenance status of ipw2x00
drivers. We remove James's name as he is not involved with this project
anymore. We also update the Status to "Odd Fixes". This has been true for a
while now, we have to make it official. There is also a new email address
with which all relevant people can be reached. The same email address
should be used for iwlwifi.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: James Ketrenos <jketreno@linux.intel.com>
Acked-by: James Ketrenos <jketreno@linux.intel.com>
Acked-by: Zhu Yi <yi.zhu@intel.com>
---
v2: Include full name "Intel Linux Wireless" for general mailing address.
MAINTAINERS | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d8d495..a8b8d28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2653,25 +2653,21 @@ F: drivers/net/ixgbe/
INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
M: Zhu Yi <yi.zhu@intel.com>
-M: James Ketrenos <jketreno@linux.intel.com>
M: Reinette Chatre <reinette.chatre@intel.com>
+M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
-L: ipw2100-devel@lists.sourceforge.net
-W: http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
W: http://ipw2100.sourceforge.net
-S: Supported
+S: Odd Fixes
F: Documentation/networking/README.ipw2100
F: drivers/net/wireless/ipw2x00/ipw2100.*
INTEL PRO/WIRELESS 2915ABG NETWORK CONNECTION SUPPORT
M: Zhu Yi <yi.zhu@intel.com>
-M: James Ketrenos <jketreno@linux.intel.com>
M: Reinette Chatre <reinette.chatre@intel.com>
+M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
-L: ipw2100-devel@lists.sourceforge.net
-W: http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
W: http://ipw2200.sourceforge.net
-S: Supported
+S: Odd Fixes
F: Documentation/networking/README.ipw2200
F: drivers/net/wireless/ipw2x00/ipw2200.*
@@ -2688,8 +2684,8 @@ F: include/linux/wimax/i2400m.h
INTEL WIRELESS WIFI LINK (iwlwifi)
M: Zhu Yi <yi.zhu@intel.com>
M: Reinette Chatre <reinette.chatre@intel.com>
+M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
-L: ipw3945-devel@lists.sourceforge.net
W: http://intellinuxwireless.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
S: Supported
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH 14/14] MAINTAINERS: Update ipw2x00 and iwlwifi entries
From: Joe Perches @ 2009-08-21 20:56 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linville, linux-wireless, James Ketrenos
In-Reply-To: <1250886867-4112-15-git-send-email-reinette.chatre@intel.com>
On Fri, 2009-08-21 at 13:34 -0700, Reinette Chatre wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
> INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
> M: Zhu Yi <yi.zhu@intel.com>
> -M: James Ketrenos <jketreno@linux.intel.com>
> M: Reinette Chatre <reinette.chatre@intel.com>
> +M: ilw@linux.intel.com
Perhaps preface these entries with a team name?
How about:
M: Intel Linux Wireless <ilw@linux.intel.com>
^ permalink raw reply
* mac80211: reassociate in STA mode after AP was power-cycled
From: Joerg Albert @ 2009-08-21 21:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
I had a ar9170usb device in STA mode associated to an AP and power-cycled the AP - slowly enough to get the
STA disassociated.
I wonder why the STA doesn't re-associate again to the AP once it's up again. Waited for 5+ minutes.
I see the AP in the output of "iwlist wlan1 scan" and after "ifconfig wlan1 down; ifconfig wlan1 up"
the STA associates quickly.
wireless-testing from today, v2.6.31-rc6-31653-g0dfdb6f.
Some lines from syslog, between "ifconfig wlan1 up" and powering off the AP:
Aug 21 22:55:33 nc10 kernel: [ 1854.824443] wlan1: direct probe to AP 00:30:f1:d5:2e:69 (try 1)
Aug 21 22:55:33 nc10 kernel: [ 1854.826914] wlan1 direct probe responded
Aug 21 22:55:33 nc10 kernel: [ 1854.826930] wlan1: authenticate with AP 00:30:f1:d5:2e:69 (try 1)
Aug 21 22:55:33 nc10 kernel: [ 1854.830003] wlan1: authenticated
Aug 21 22:55:33 nc10 kernel: [ 1854.837585] wlan1: associate with AP 00:30:f1:d5:2e:69 (try 1)
Aug 21 22:55:33 nc10 kernel: [ 1854.839656] wlan1: RX AssocResp from 00:30:f1:d5:2e:69 (capab=0x421 status=0 aid=5)
Aug 21 22:55:33 nc10 kernel: [ 1854.839670] wlan1: associated
Aug 21 22:55:33 nc10 kernel: [ 1854.847296] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Aug 21 22:55:45 nc10 kernel: [ 1867.500169] No probe response from AP 00:30:f1:d5:2e:69 after 500ms, disconnecting.
Regards,
Jörg.
^ permalink raw reply
* Re: mac80211: reassociate in STA mode after AP was power-cycled
From: Johannes Berg @ 2009-08-21 21:23 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4A8F0D8D.7000508@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
On Fri, 2009-08-21 at 23:11 +0200, Joerg Albert wrote:
> I had a ar9170usb device in STA mode associated to an AP and power-cycled the AP - slowly enough to get the
> STA disassociated.
>
> I wonder why the STA doesn't re-associate again to the AP once it's up again. Waited for 5+ minutes.
It told userspace that it disconnected, and as such it can't do anything
any more. Just run wpa_supplicant.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2 v2] ar9170: remove unnecessary call to ar9170_set_beacon_timers
From: Christian Lamparter @ 2009-08-21 21:24 UTC (permalink / raw)
To: Joerg Albert; +Cc: John W. Linville, linux-wireless@vger.kernel.org
In-Reply-To: <4A8F0951.50108@gmx.de>
On Friday 21 August 2009 22:53:37 Joerg Albert wrote:
>
> Signed-off-by: Joerg Albert <jal2@gmx.de>
Acked-by: Christian Lamparter <chunkeey@web.de>
> ---
> drivers/net/wireless/ath/ar9170/main.c | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
> index 911e502..5b73194 100644
> --- a/drivers/net/wireless/ath/ar9170/main.c
> +++ b/drivers/net/wireless/ath/ar9170/main.c
> @@ -2031,12 +2031,6 @@ static int ar9170_op_config(struct ieee80211_hw *hw, u32 changed)
> goto out;
> }
>
> - if (changed & BSS_CHANGED_BEACON_INT) {
> - err = ar9170_set_beacon_timers(ar);
> - if (err)
> - goto out;
> - }
> -
> if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
>
> /* adjust slot time for 5 GHz */
>
^ permalink raw reply
* [PATCH 1/2 v3] ar9170: cleanup of bss_info_changed and beacon config
From: Christian Lamparter @ 2009-08-21 21:25 UTC (permalink / raw)
To: Joerg Albert; +Cc: John W. Linville, linux-wireless@vger.kernel.org
In-Reply-To: <4A8F0798.6050908@gmx.de>
From: Joerg Albert <jal2@gmx.de>
Add beacon control by BSS_CHANGED_BEACON_ENABLED and
bss_conf->enable_beacon from mac80211.
Signed-off-by: Joerg Albert <jal2@gmx.de>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
About time they show up ;-)
changes from v2:
- fixed both checkpatch.pl complains
- removed a few empty lines.
hope this one is fine...
---
diff --git a/drivers/net/wireless/ath/ar9170/ar9170.h b/drivers/net/wireless/ath/ar9170/ar9170.h
index ce40724..914e471 100644
--- a/drivers/net/wireless/ath/ar9170/ar9170.h
+++ b/drivers/net/wireless/ath/ar9170/ar9170.h
@@ -178,6 +178,7 @@ struct ar9170 {
/* beaconing */
struct sk_buff *beacon;
struct work_struct beacon_work;
+ bool enable_beacon;
/* cryptographic engine */
u64 usedkeys;
diff --git a/drivers/net/wireless/ath/ar9170/mac.c b/drivers/net/wireless/ath/ar9170/mac.c
index 6004936..614e321 100644
--- a/drivers/net/wireless/ath/ar9170/mac.c
+++ b/drivers/net/wireless/ath/ar9170/mac.c
@@ -383,24 +383,26 @@ int ar9170_set_beacon_timers(struct ar9170 *ar)
if (ar->vif) {
v |= ar->vif->bss_conf.beacon_int;
- switch (ar->vif->type) {
- case NL80211_IFTYPE_MESH_POINT:
- case NL80211_IFTYPE_ADHOC:
- v |= BIT(25);
- break;
- case NL80211_IFTYPE_AP:
- v |= BIT(24);
- pretbtt = (ar->vif->bss_conf.beacon_int - 6) << 16;
- break;
- default:
+ if (ar->enable_beacon) {
+ switch (ar->vif->type) {
+ case NL80211_IFTYPE_MESH_POINT:
+ case NL80211_IFTYPE_ADHOC:
+ v |= BIT(25);
+ break;
+ case NL80211_IFTYPE_AP:
+ v |= BIT(24);
+ pretbtt = (ar->vif->bss_conf.beacon_int - 6) <<
+ 16;
+ break;
+ default:
break;
+ }
}
v |= ar->vif->bss_conf.dtim_period << 16;
}
ar9170_regwrite_begin(ar);
-
ar9170_regwrite(AR9170_MAC_REG_PRETBTT, pretbtt);
ar9170_regwrite(AR9170_MAC_REG_BCN_PERIOD, v);
ar9170_regwrite_finish();
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index 658b323..c0fc355 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -2148,11 +2148,17 @@ static void ar9170_op_bss_info_changed(struct ieee80211_hw *hw,
goto out;
}
- if (changed & (BSS_CHANGED_BEACON | BSS_CHANGED_BEACON_ENABLED)) {
+ if (changed & BSS_CHANGED_BEACON_ENABLED)
+ ar->enable_beacon = bss_conf->enable_beacon;
+
+ if (changed & BSS_CHANGED_BEACON) {
err = ar9170_update_beacon(ar);
if (err)
goto out;
+ }
+ if (changed & (BSS_CHANGED_BEACON_ENABLED | BSS_CHANGED_BEACON |
+ BSS_CHANGED_BEACON_INT)) {
err = ar9170_set_beacon_timers(ar);
if (err)
goto out;
@@ -2165,12 +2171,6 @@ static void ar9170_op_bss_info_changed(struct ieee80211_hw *hw,
#endif /* CONFIG_AR9170_LEDS */
}
- if (changed & BSS_CHANGED_BEACON_INT) {
- err = ar9170_set_beacon_timers(ar);
- if (err)
- goto out;
- }
-
if (changed & BSS_CHANGED_HT) {
/* TODO */
err = 0;
^ permalink raw reply related
* Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: Larry Finger @ 2009-08-21 21:34 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <jCYznkTxcLB.A.EPH.eNIjKB@chimera>
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13960
> Subject : rtl8187 not connect to wifi
> Submitter : okias <d.okias@gmail.com>
> Date : 2009-08-10 19:16 (10 days old)
The patch for this one was sent from Linville to DaveM earlier today,
and should be sent to mainline in the near future.
AFAIK, the OP has not yet tested the patch, but I think I was able to
reproduce the problem, and the patch did fit it for me.
Larry
^ permalink raw reply
* [PATCH] compal-laptop: Replace sysfs support with rfkill support
From: Mario Limonciello @ 2009-08-21 21:39 UTC (permalink / raw)
To: cezary.jackiewicz
Cc: linux-wireless, linux-acpi, linux-kernel, Mario Limonciello
In-Reply-To: <1250706969-10382-1-git-send-email-Mario_Limonciello@Dell.com>
This drops the support for manually groking the files in sysfs
to turn on and off the WLAN and BT for Compal laptops in favor
of platform rfkill support.
It has been combined into a single patch to not introduce regressions
in the process of simply adding rfkill support.
Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
Reviewed-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/compal-laptop.c | 203 +++++++++++-----------------------
1 files changed, 63 insertions(+), 140 deletions(-)
diff --git a/drivers/platform/x86/compal-laptop.c b/drivers/platform/x86/compal-laptop.c
index c1c8c03..2c1ff8f 100644
--- a/drivers/platform/x86/compal-laptop.c
+++ b/drivers/platform/x86/compal-laptop.c
@@ -26,17 +26,8 @@
/*
* comapl-laptop.c - Compal laptop support.
*
- * This driver exports a few files in /sys/devices/platform/compal-laptop/:
- *
- * wlan - wlan subsystem state: contains 0 or 1 (rw)
- *
- * bluetooth - Bluetooth subsystem state: contains 0 or 1 (rw)
- *
- * raw - raw value taken from embedded controller register (ro)
- *
- * In addition to these platform device attributes the driver
- * registers itself in the Linux backlight control subsystem and is
- * available to userspace under /sys/class/backlight/compal-laptop/.
+ * The driver registers itself with the rfkill subsystem and
+ * the Linux backlight control subsystem.
*
* This driver might work on other laptops produced by Compal. If you
* want to try it you can pass force=1 as argument to the module which
@@ -52,6 +43,7 @@
#include <linux/backlight.h>
#include <linux/platform_device.h>
#include <linux/autoconf.h>
+#include <linux/rfkill.h>
#define COMPAL_DRIVER_VERSION "0.2.6"
@@ -64,6 +56,10 @@
#define WLAN_MASK 0x01
#define BT_MASK 0x02
+static struct rfkill *wifi_rfkill;
+static struct rfkill *bt_rfkill;
+static struct platform_device *compal_device;
+
static int force;
module_param(force, bool, 0);
MODULE_PARM_DESC(force, "Force driver load, ignore DMI data");
@@ -89,65 +85,75 @@ static int get_lcd_level(void)
return (int) result;
}
-static int set_wlan_state(int state)
+static int compal_rfkill_set(void *data, bool blocked)
{
+ unsigned long radio = (unsigned long) data;
u8 result, value;
ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
- if ((result & KILLSWITCH_MASK) == 0)
- return -EINVAL;
- else {
- if (state)
- value = (u8) (result | WLAN_MASK);
- else
- value = (u8) (result & ~WLAN_MASK);
- ec_write(COMPAL_EC_COMMAND_WIRELESS, value);
- }
+ if (!blocked)
+ value = (u8) (result | radio);
+ else
+ value = (u8) (result & ~radio);
+ ec_write(COMPAL_EC_COMMAND_WIRELESS, value);
return 0;
}
-static int set_bluetooth_state(int state)
+static void compal_rfkill_poll(struct rfkill *rfkill, void *data)
{
- u8 result, value;
+ u8 result;
+ bool hw_blocked;
ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
- if ((result & KILLSWITCH_MASK) == 0)
- return -EINVAL;
- else {
- if (state)
- value = (u8) (result | BT_MASK);
- else
- value = (u8) (result & ~BT_MASK);
- ec_write(COMPAL_EC_COMMAND_WIRELESS, value);
- }
-
- return 0;
+ hw_blocked = !(result & KILLSWITCH_MASK);
+ rfkill_set_hw_state(rfkill, hw_blocked);
}
-static int get_wireless_state(int *wlan, int *bluetooth)
+static const struct rfkill_ops compal_rfkill_ops = {
+ .poll = compal_rfkill_poll,
+ .set_block = compal_rfkill_set,
+};
+
+static int setup_rfkill(void)
{
- u8 result;
+ int ret;
- ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
+ wifi_rfkill = rfkill_alloc("compal-wifi", &compal_device->dev,
+ RFKILL_TYPE_WLAN, &compal_rfkill_ops,
+ (void *) WLAN_MASK);
+ if (!wifi_rfkill)
+ return -ENOMEM;
- if (wlan) {
- if ((result & KILLSWITCH_MASK) == 0)
- *wlan = 0;
- else
- *wlan = result & WLAN_MASK;
- }
+ ret = rfkill_register(wifi_rfkill);
+ if (ret)
+ goto err_wifi;
- if (bluetooth) {
- if ((result & KILLSWITCH_MASK) == 0)
- *bluetooth = 0;
- else
- *bluetooth = (result & BT_MASK) >> 1;
+ bt_rfkill = rfkill_alloc("compal-bluetooth", &compal_device->dev,
+ RFKILL_TYPE_BLUETOOTH, &compal_rfkill_ops,
+ (void *) BT_MASK);
+ if (!bt_rfkill) {
+ ret = -ENOMEM;
+ goto err_allocate_bt;
}
+ ret = rfkill_register(bt_rfkill);
+ if (ret)
+ goto err_register_bt;
return 0;
+
+err_register_bt:
+ rfkill_destroy(bt_rfkill);
+
+err_allocate_bt:
+ rfkill_unregister(wifi_rfkill);
+
+err_wifi:
+ rfkill_destroy(wifi_rfkill);
+
+ return ret;
}
/* Backlight device stuff */
@@ -170,86 +176,6 @@ static struct backlight_ops compalbl_ops = {
static struct backlight_device *compalbl_device;
-/* Platform device */
-
-static ssize_t show_wlan(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- int ret, enabled;
-
- ret = get_wireless_state(&enabled, NULL);
- if (ret < 0)
- return ret;
-
- return sprintf(buf, "%i\n", enabled);
-}
-
-static ssize_t show_raw(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- u8 result;
-
- ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
-
- return sprintf(buf, "%i\n", result);
-}
-
-static ssize_t show_bluetooth(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- int ret, enabled;
-
- ret = get_wireless_state(NULL, &enabled);
- if (ret < 0)
- return ret;
-
- return sprintf(buf, "%i\n", enabled);
-}
-
-static ssize_t store_wlan_state(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
-{
- int state, ret;
-
- if (sscanf(buf, "%i", &state) != 1 || (state < 0 || state > 1))
- return -EINVAL;
-
- ret = set_wlan_state(state);
- if (ret < 0)
- return ret;
-
- return count;
-}
-
-static ssize_t store_bluetooth_state(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
-{
- int state, ret;
-
- if (sscanf(buf, "%i", &state) != 1 || (state < 0 || state > 1))
- return -EINVAL;
-
- ret = set_bluetooth_state(state);
- if (ret < 0)
- return ret;
-
- return count;
-}
-
-static DEVICE_ATTR(bluetooth, 0644, show_bluetooth, store_bluetooth_state);
-static DEVICE_ATTR(wlan, 0644, show_wlan, store_wlan_state);
-static DEVICE_ATTR(raw, 0444, show_raw, NULL);
-
-static struct attribute *compal_attributes[] = {
- &dev_attr_bluetooth.attr,
- &dev_attr_wlan.attr,
- &dev_attr_raw.attr,
- NULL
-};
-
-static struct attribute_group compal_attribute_group = {
- .attrs = compal_attributes
-};
static struct platform_driver compal_driver = {
.driver = {
@@ -258,8 +184,6 @@ static struct platform_driver compal_driver = {
}
};
-static struct platform_device *compal_device;
-
/* Initialization */
static int dmi_check_cb(const struct dmi_system_id *id)
@@ -390,23 +314,19 @@ static int __init compal_init(void)
ret = platform_device_add(compal_device);
if (ret)
- goto fail_platform_device1;
+ goto fail_platform_device;
- ret = sysfs_create_group(&compal_device->dev.kobj,
- &compal_attribute_group);
+ ret = setup_rfkill();
if (ret)
- goto fail_platform_device2;
+ goto fail_rfkill;
printk(KERN_INFO "compal-laptop: driver "COMPAL_DRIVER_VERSION
" successfully loaded.\n");
return 0;
-fail_platform_device2:
-
- platform_device_del(compal_device);
-
-fail_platform_device1:
+fail_rfkill:
+fail_platform_device:
platform_device_put(compal_device);
@@ -424,10 +344,13 @@ fail_backlight:
static void __exit compal_cleanup(void)
{
- sysfs_remove_group(&compal_device->dev.kobj, &compal_attribute_group);
platform_device_unregister(compal_device);
platform_driver_unregister(&compal_driver);
backlight_device_unregister(compalbl_device);
+ rfkill_unregister(wifi_rfkill);
+ rfkill_destroy(wifi_rfkill);
+ rfkill_unregister(bt_rfkill);
+ rfkill_destroy(bt_rfkill);
printk(KERN_INFO "compal-laptop: driver unloaded.\n");
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCHv4] b43 add harware tkip
From: gregor kowski @ 2009-08-21 21:43 UTC (permalink / raw)
To: Kalle Valo; +Cc: bcm43xx-dev, Michael Buesch, linux-wireless
In-Reply-To: <87eir6tueg.fsf@litku.valot.fi>
This add hardware tkip for b43. This can help to reduce the load a low
powered router and make higher throughput. To enable it, you need to
set "hwtkip" module param.
Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
Acked-by: Michael Buesch <mb@bu3sch.de>
Index: linux-2.6/drivers/net/wireless/b43/dma.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/dma.c 2009-08-10
20:35:33.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/dma.c 2009-08-21 21:26:02.000000000 +0000
@@ -1188,7 +1188,7 @@
header = &(ring->txhdr_cache[(slot / TX_SLOTS_PER_FRAME) * hdrsize]);
cookie = generate_cookie(ring, slot);
err = b43_generate_txhdr(ring->dev, header,
- skb->data, skb->len, info, cookie);
+ skb, info, cookie);
if (unlikely(err)) {
ring->current_slot = old_top_slot;
ring->used_slots = old_used_slots;
Index: linux-2.6/drivers/net/wireless/b43/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/main.c 2009-08-10
20:35:42.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/main.c 2009-08-21
21:26:02.000000000 +0000
@@ -80,6 +80,10 @@
module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
+static int modparam_hwtkip;
+module_param_named(hwtkip, modparam_hwtkip, int, 0444);
+MODULE_PARM_DESC(hwtkip, "Enable hardware tkip.");
+
static int modparam_qos = 1;
module_param_named(qos, modparam_qos, int, 0444);
MODULE_PARM_DESC(qos, "Enable QOS support (default on)");
@@ -826,6 +830,85 @@
(index * 2) + 1, addrtmp[1]);
}
+/* The ucode will use phase1 key with TEK key to decrypt rx packets.
+ * When a packet is received, the iv32 is checked.
+ * - if it doesn't the packet is returned without modification (and software
+ * decryption can be done). That's what happen when iv16 wrap.
+ * - if it does, the rc4 key is computed, and decryption is tried.
+ * Either it will success and B43_RX_MAC_DEC is returned,
+ * either it fails and B43_RX_MAC_DEC|B43_RX_MAC_DECERR is returned
+ * and the packet is not usable (it got modified by the ucode).
+ * So in order to never have B43_RX_MAC_DECERR, we should provide
+ * a iv32 and phase1key that match. Because we drop packets in case of
+ * B43_RX_MAC_DECERR, if we have a correct iv32 but a wrong phase1key, all
+ * packets will be lost without higher layer knowing (ie no resync possible
+ * until next wrap).
+ *
+ * NOTE : this should support 50 key like RCMTA because
+ * (B43_SHM_SH_KEYIDXBLOCK - B43_SHM_SH_TKIPTSCTTAK)/14 = 50
+ */
+static void rx_tkip_phase1_write(struct b43_wldev *dev, u8 index, u32 iv32,
+ u16 *phase1key)
+{
+ unsigned int i;
+ u32 offset;
+ u8 pairwise_keys_start = B43_NR_GROUP_KEYS * 2;
+
+ if (!modparam_hwtkip)
+ return;
+
+ if (b43_new_kidx_api(dev))
+ pairwise_keys_start = B43_NR_GROUP_KEYS;
+
+ B43_WARN_ON(index < pairwise_keys_start);
+ /* We have four default TX keys and possibly four default RX keys.
+ * Physical mac 0 is mapped to physical key 4 or 8, depending
+ * on the firmware version.
+ * So we must adjust the index here.
+ */
+ index -= pairwise_keys_start;
+ B43_WARN_ON(index >= B43_NR_PAIRWISE_KEYS);
+
+ if (b43_debug(dev, B43_DBG_KEYS)) {
+ b43dbg(dev->wl, "rx_tkip_phase1_write : idx 0x%x, iv32 0x%x\n",
+ index, iv32);
+ }
+ /* Write the key to the RX tkip shared mem */
+ offset = B43_SHM_SH_TKIPTSCTTAK + index * (10 + 4);
+ for (i = 0; i < 10; i += 2) {
+ b43_shm_write16(dev, B43_SHM_SHARED, offset + i,
+ phase1key ? phase1key[i / 2] : 0);
+ }
+ b43_shm_write16(dev, B43_SHM_SHARED, offset + i, iv32);
+ b43_shm_write16(dev, B43_SHM_SHARED, offset + i + 2, iv32 >> 16);
+}
+
+static void b43_op_update_tkip_key(struct ieee80211_hw *hw,
+ struct ieee80211_key_conf *keyconf, const u8 *addr,
+ u32 iv32, u16 *phase1key)
+{
+ struct b43_wl *wl = hw_to_b43_wl(hw);
+ struct b43_wldev *dev;
+ int index = keyconf->hw_key_idx;
+
+ if (B43_WARN_ON(!modparam_hwtkip))
+ return;
+
+ mutex_lock(&wl->mutex);
+
+ dev = wl->current_dev;
+ if (!dev || b43_status(dev) < B43_STAT_INITIALIZED)
+ goto out_unlock;
+
+ keymac_write(dev, index, NULL); /* First zero out mac to avoid race */
+
+ rx_tkip_phase1_write(dev, index, iv32, phase1key);
+ keymac_write(dev, index, addr);
+
+out_unlock:
+ mutex_unlock(&wl->mutex);
+}
+
static void do_key_write(struct b43_wldev *dev,
u8 index, u8 algorithm,
const u8 *key, size_t key_len, const u8 *mac_addr)
@@ -841,6 +924,19 @@
if (index >= pairwise_keys_start)
keymac_write(dev, index, NULL); /* First zero out mac. */
+ if (algorithm == B43_SEC_ALGO_TKIP) {
+ /*
+ * We should provide an initial iv32, phase1key pair.
+ * We could start with iv32=0 and compute the corresponding
+ * phase1key, but this means calling ieee80211_get_tkip_key
+ * with a fake skb (or export other tkip function).
+ * Because we are lazy we hope iv32 won't start with
+ * 0xffffffff and let's b43_op_update_tkip_key provide a
+ * correct pair.
+ */
+ rx_tkip_phase1_write(dev, index, 0xffffffff, (u16*)buf);
+ } else if (index >= pairwise_keys_start) /* clear it */
+ rx_tkip_phase1_write(dev, index, 0, NULL);
if (key)
memcpy(buf, key, key_len);
key_write(dev, index, algorithm, buf);
@@ -859,6 +955,15 @@
int i;
int pairwise_keys_start;
+ /* For ALG_TKIP the key is encoded as a 256-bit (32 byte) data block:
+ * - Temporal Encryption Key (128 bits)
+ * - Temporal Authenticator Tx MIC Key (64 bits)
+ * - Temporal Authenticator Rx MIC Key (64 bits)
+ *
+ * Hardware only store TEK
+ */
+ if (algorithm == B43_SEC_ALGO_TKIP && key_len == 32)
+ key_len = 16;
if (key_len > B43_SEC_KEYSIZE)
return -EINVAL;
for (i = 0; i < ARRAY_SIZE(dev->key); i++) {
@@ -965,6 +1070,14 @@
printk(" Algo: %04X/%02X", algo, key->algorithm);
if (index >= pairwise_keys_start) {
+ if (key->algorithm == B43_SEC_ALGO_TKIP) {
+ printk(" TKIP: ");
+ offset = B43_SHM_SH_TKIPTSCTTAK + (index - 4) * (10 + 4);
+ for (i = 0; i < 14; i += 2) {
+ u16 tmp = b43_shm_read16(dev, B43_SHM_SHARED, offset + i);
+ printk("%02X%02X", (tmp & 0xFF), ((tmp >> 8) & 0xFF));
+ }
+ }
rcmta0 = b43_shm_read32(dev, B43_SHM_RCMTA,
((index - pairwise_keys_start) * 2) + 0);
rcmta1 = b43_shm_read16(dev, B43_SHM_RCMTA,
@@ -3587,8 +3700,10 @@
switch (cmd) {
case SET_KEY:
- if (algorithm == B43_SEC_ALGO_TKIP) {
- /* FIXME: No TKIP hardware encryption for now. */
+ if (algorithm == B43_SEC_ALGO_TKIP &&
+ (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE) ||
+ !modparam_hwtkip)) {
+ /* We support only pairwise key */
err = -EOPNOTSUPP;
goto out_unlock;
}
@@ -3618,6 +3733,8 @@
b43_hf_read(dev) & ~B43_HF_USEDEFKEYS);
}
key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
+ if (algorithm == B43_SEC_ALGO_TKIP)
+ key->flags |= IEEE80211_KEY_FLAG_GENERATE_MMIC;
break;
case DISABLE_KEY: {
err = b43_key_clear(dev, key->hw_key_idx);
@@ -4345,6 +4462,7 @@
.bss_info_changed = b43_op_bss_info_changed,
.configure_filter = b43_op_configure_filter,
.set_key = b43_op_set_key,
+ .update_tkip_key = b43_op_update_tkip_key,
.get_stats = b43_op_get_stats,
.get_tx_stats = b43_op_get_tx_stats,
.get_tsf = b43_op_get_tsf,
Index: linux-2.6/drivers/net/wireless/b43/pio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/pio.c 2009-08-10
20:35:33.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/pio.c 2009-08-21 21:26:02.000000000 +0000
@@ -461,8 +461,8 @@
cookie = generate_cookie(q, pack);
hdrlen = b43_txhdr_size(q->dev);
- err = b43_generate_txhdr(q->dev, (u8 *)&txhdr, skb->data,
- skb->len, info, cookie);
+ err = b43_generate_txhdr(q->dev, (u8 *)&txhdr, skb,
+ info, cookie);
if (err)
return err;
Index: linux-2.6/drivers/net/wireless/b43/xmit.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/xmit.c 2009-08-10
20:35:42.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/xmit.c 2009-08-21
21:26:02.000000000 +0000
@@ -180,11 +180,12 @@
/* Generate a TX data header. */
int b43_generate_txhdr(struct b43_wldev *dev,
u8 *_txhdr,
- const unsigned char *fragment_data,
- unsigned int fragment_len,
+ struct sk_buff *skb_frag,
struct ieee80211_tx_info *info,
u16 cookie)
{
+ const unsigned char *fragment_data = skb_frag->data;
+ unsigned int fragment_len = skb_frag->len;
struct b43_txhdr *txhdr = (struct b43_txhdr *)_txhdr;
const struct b43_phy *phy = &dev->phy;
const struct ieee80211_hdr *wlhdr =
@@ -258,9 +259,26 @@
mac_ctl |= (key->algorithm << B43_TXH_MAC_KEYALG_SHIFT) &
B43_TXH_MAC_KEYALG;
wlhdr_len = ieee80211_hdrlen(fctl);
- iv_len = min((size_t) info->control.hw_key->iv_len,
- ARRAY_SIZE(txhdr->iv));
- memcpy(txhdr->iv, ((u8 *) wlhdr) + wlhdr_len, iv_len);
+ if (key->algorithm == B43_SEC_ALGO_TKIP) {
+ u16 phase1key[5];
+ int i;
+ /* we give the phase1key and iv16 here, the key is stored in
+ * shm. With that the hardware can do phase 2 and encryption.
+ */
+ ieee80211_get_tkip_key(info->control.hw_key, skb_frag,
+ IEEE80211_TKIP_P1_KEY, (u8*)phase1key);
+ /* phase1key is in host endian */
+ for (i = 0; i < 5; i++)
+ phase1key[i] = cpu_to_le16(phase1key[i]);
+
+ memcpy(txhdr->iv, phase1key, 10);
+ /* iv16 */
+ memcpy(txhdr->iv + 10, ((u8 *) wlhdr) + wlhdr_len, 3);
+ } else {
+ iv_len = min((size_t) info->control.hw_key->iv_len,
+ ARRAY_SIZE(txhdr->iv));
+ memcpy(txhdr->iv, ((u8 *) wlhdr) + wlhdr_len, iv_len);
+ }
}
if (b43_is_old_txhdr_format(dev)) {
b43_generate_plcp_hdr((struct b43_plcp_hdr4 *)(&txhdr->old_format.plcp),
Index: linux-2.6/drivers/net/wireless/b43/xmit.h
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/xmit.h 2009-08-10
20:35:33.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/xmit.h 2009-08-21
21:26:02.000000000 +0000
@@ -176,8 +176,7 @@
int b43_generate_txhdr(struct b43_wldev *dev,
u8 * txhdr,
- const unsigned char *fragment_data,
- unsigned int fragment_len,
+ struct sk_buff *skb_frag,
struct ieee80211_tx_info *txctl, u16 cookie);
/* Transmit Status */
^ permalink raw reply
* Re: Plans for an online meeting regarding Radiotap
From: Gábor Stefanik @ 2009-08-21 21:55 UTC (permalink / raw)
To: Johannes Berg
Cc: Richard Farina, Mike Kershaw, Sam Leffler, Rafael Laufer,
Damien Bergamini, Sepherosa Ziehau, Thomas d'Otreppe,
Dave Young, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <1250867479.4600.11.camel@johannes.local>
2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2009-08-21 at 17:04 +0200, Gábor Stefanik wrote:
>
>> I've reworked RTS/CTS since then, just haven't got to sending a new
>> proposal yet. The current plan is as follows:
>>
>> TX_FLAGS & 0x0002: Use CTS
>> TX_FLAGS & 0x0004: Use RTS
>> TX_FLAGS & 0x0020: Disable RTS/CTS usage
>
> Seems a bit strange, wouldn't setting neither RTS nor CTS have the
> effect? Seems like 0x20 should rather be "use automatic and ignore the
> other bits". Anyway, not appropriate here, you should just bring a new
> proposal.
The point is that if all bits are 0, auto-setup is used. The problem
with my original proposal (using two bits) was that an all-zero value
had different effect than not including the TX flags field (and simply
swapping "none" and "auto" would result in an illogicality where what
would logically be "use both" would become "use neither" - just the
opposite of its logical meaning). Making 0x20 mean "Auto-select
RTS/CTS", interpreting all-zeros as "Use neither", would have the same
problem as my proposal - all-zeros is different from a missing field.
(An empty, zeroed field 15 should have no effect on the process,
behaving as if field 15 was not present in the header.)
>
>> If I remember correctly, I made an implementation for the Linux kernel
>> (a generator-side implementation) and one for Wireshark (a parser-side
>> implementation). Or should I make two generator-side implementations
>> according to the requirement (e.g. one for Linux, another for
>> OpenBSD)?
>
> No, that was ok, I just meant that therefore by definition it can't be a
> problem of lack of implementations.
>
> johannes
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-21 22:02 UTC (permalink / raw)
To: Larry Finger
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <4A8F12CE.9090601@lwfinger.net>
On Friday 21 August 2009, Larry Finger wrote:
> Rafael J. Wysocki wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13960
> > Subject : rtl8187 not connect to wifi
> > Submitter : okias <d.okias@gmail.com>
> > Date : 2009-08-10 19:16 (10 days old)
>
> The patch for this one was sent from Linville to DaveM earlier today,
> and should be sent to mainline in the near future.
>
> AFAIK, the OP has not yet tested the patch, but I think I was able to
> reproduce the problem, and the patch did fit it for me.
Thanks for the update.
Can you please close the bug when the patch is merged?
Rafael
^ permalink raw reply
* [PATCH] mac80211 : fix a race with update_tkip_key
From: gregor kowski @ 2009-08-21 22:13 UTC (permalink / raw)
To: linux-wireless
The mac80211 tkip code won't call update_tkip_key, if some rx packets
get received without KEY_FLAG_UPLOADED_TO_HARDWARE. This can happen on
first packet because the hardware key stuff is called asynchronously with
todo workqueue.
This patch workaround that by tracking if we send the key to hardware.
Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
Index: linux-2.6/net/mac80211/tkip.c
===================================================================
--- linux-2.6.orig/net/mac80211/tkip.c 2009-06-30 20:27:02.000000000 +0000
+++ linux-2.6/net/mac80211/tkip.c 2009-08-21 22:02:34.000000000 +0000
@@ -100,7 +100,7 @@
p1k[3] += tkipS(p1k[2] ^ get_unaligned_le16(tk + 12 + j));
p1k[4] += tkipS(p1k[3] ^ get_unaligned_le16(tk + 0 + j)) + i;
}
- ctx->initialized = 1;
+ ctx->initialized = TKIP_INITIALIZED_PHASE1;
}
static void tkip_mixing_phase2(const u8 *tk, struct tkip_ctx *ctx,
@@ -183,7 +183,7 @@
/* Update the p1k only when the iv16 in the packet wraps around, this
* might occur after the wrap around of iv16 in the key in case of
* fragmented packets. */
- if (iv16 == 0 || !ctx->initialized)
+ if (iv16 == 0 || ctx->initialized == TKIP_INITIALIZED_NONE)
tkip_mixing_phase1(tk, ctx, hdr->addr2, iv32);
if (type == IEEE80211_TKIP_P1_KEY) {
@@ -209,7 +209,7 @@
const u8 *tk = &key->conf.key[NL80211_TKIP_DATA_OFFSET_ENCR_KEY];
/* Calculate per-packet key */
- if (ctx->iv16 == 0 || !ctx->initialized)
+ if (ctx->iv16 == 0 || ctx->initialized == TKIP_INITIALIZED_NONE)
tkip_mixing_phase1(tk, ctx, ta, ctx->iv32);
tkip_mixing_phase2(tk, ctx, ctx->iv16, rc4key);
@@ -259,7 +259,7 @@
if ((keyid >> 6) != key->conf.keyidx)
return TKIP_DECRYPT_INVALID_KEYIDX;
- if (key->u.tkip.rx[queue].initialized &&
+ if (key->u.tkip.rx[queue].initialized != TKIP_INITIALIZED_NONE &&
(iv32 < key->u.tkip.rx[queue].iv32 ||
(iv32 == key->u.tkip.rx[queue].iv32 &&
iv16 <= key->u.tkip.rx[queue].iv16))) {
@@ -275,11 +275,11 @@
if (only_iv) {
res = TKIP_DECRYPT_OK;
- key->u.tkip.rx[queue].initialized = 1;
+ key->u.tkip.rx[queue].initialized = TKIP_INITIALIZED_UPDATE_KEY;
goto done;
}
- if (!key->u.tkip.rx[queue].initialized ||
+ if (key->u.tkip.rx[queue].initialized == TKIP_INITIALIZED_NONE ||
key->u.tkip.rx[queue].iv32 != iv32) {
/* IV16 wrapped around - perform TKIP phase 1 */
tkip_mixing_phase1(tk, &key->u.tkip.rx[queue], ta, iv32);
@@ -299,18 +299,20 @@
printk("\n");
}
#endif
- if (key->local->ops->update_tkip_key &&
- key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
- u8 bcast[ETH_ALEN] =
- {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
- u8 *sta_addr = key->sta->sta.addr;
-
- if (is_multicast_ether_addr(ra))
- sta_addr = bcast;
-
- drv_update_tkip_key(key->local, &key->conf, sta_addr,
- iv32, key->u.tkip.rx[queue].p1k);
- }
+ }
+ if (key->local->ops->update_tkip_key &&
+ key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE &&
+ key->u.tkip.rx[queue].initialized != TKIP_INITIALIZED_UPDATE_KEY) {
+ u8 bcast[ETH_ALEN] =
+ {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+ u8 *sta_addr = key->sta->sta.addr;
+
+ if (is_multicast_ether_addr(ra))
+ sta_addr = bcast;
+
+ drv_update_tkip_key(key->local, &key->conf, sta_addr,
+ iv32, key->u.tkip.rx[queue].p1k);
+ key->u.tkip.rx[queue].initialized = TKIP_INITIALIZED_UPDATE_KEY;
}
tkip_mixing_phase2(tk, &key->u.tkip.rx[queue], iv16, rc4key);
Index: linux-2.6/net/mac80211/key.h
===================================================================
--- linux-2.6.orig/net/mac80211/key.h 2009-08-21 22:03:09.000000000 +0000
+++ linux-2.6/net/mac80211/key.h 2009-08-21 22:03:12.000000000 +0000
@@ -59,11 +59,17 @@
KEY_FLAG_TODO_DEFMGMTKEY = BIT(6),
};
+enum ieee80211_internal_tkip_initialized {
+ TKIP_INITIALIZED_NONE,
+ TKIP_INITIALIZED_PHASE1,
+ TKIP_INITIALIZED_UPDATE_KEY,
+};
+
struct tkip_ctx {
u32 iv32;
u16 iv16;
u16 p1k[5];
- int initialized;
+ enum ieee80211_internal_tkip_initialized initialized;
};
struct ieee80211_key {
^ permalink raw reply
* Re: mac80211: reassociate in STA mode after AP was power-cycled
From: Joerg Albert @ 2009-08-21 23:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1250889836.4600.21.camel@johannes.local>
On 08/21/2009 11:23 PM, Johannes Berg wrote:
> On Fri, 2009-08-21 at 23:11 +0200, Joerg Albert wrote:
>> I had a ar9170usb device in STA mode associated to an AP and power-cycled the AP - slowly enough to get the
>> STA disassociated.
>>
>> I wonder why the STA doesn't re-associate again to the AP once it's up again. Waited for 5+ minutes.
>
> It told userspace that it disconnected, and as such it can't do anything
> any more. Just run wpa_supplicant.
Thanks, that helped. I wasn't aware that wpa_supplicant controls non-wpa connections, too.
Jörg.
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Joerg Albert @ 2009-08-21 23:36 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John Linville, Johannes Berg
In-Reply-To: <200908212252.41053.chunkeey@web.de>
On 08/21/2009 10:52 PM, Christian Lamparter wrote:
> This patch adds some more bits from the vendor driver, which
> are supposed to help users with the one-stage/openfw firmwares.
The otus driver sets phy registers 672-703 only for the one-stage firmware -
hal/hpmain.c, line 3445:
#ifndef ZM_OTUS_LINUX_PHASE_2
reg_write(regAddr + i, val); /* CR672 */
#endif
Are you sure it doesn't hurt with the two-stage firmware?
Jörg
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Christian Lamparter @ 2009-08-21 23:51 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless, John Linville, Johannes Berg
In-Reply-To: <4A8F2F71.1010100@gmx.de>
On Saturday 22 August 2009 01:36:17 Joerg Albert wrote:
> On 08/21/2009 10:52 PM, Christian Lamparter wrote:
> > This patch adds some more bits from the vendor driver, which
> > are supposed to help users with the one-stage/openfw firmwares.
>
> The otus driver sets phy registers 672-703 only for the one-stage firmware -
> hal/hpmain.c, line 3445:
>
> #ifndef ZM_OTUS_LINUX_PHASE_2
> reg_write(regAddr + i, val); /* CR672 */
> #endif
>
> Are you sure it doesn't hurt with the two-stage firmware?
no idea, that's why I ask requested input, instead of posting a patch +
sob right away.
so far, I haven't heard of or experienced any regressions or anomalies.
Do you already have comments or complains? :)
Regards,
Chr
^ permalink raw reply
* [RFC/RFT] rtl8187: Implement rfkill support
From: Herton Ronaldo Krzesinski @ 2009-08-22 3:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Larry Finger, Hin-Tak Leung
This change implements rfkill support for RTL8187B and RTL8187L devices,
using new cfg80211 rfkill API.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
---
drivers/net/wireless/rtl818x/Makefile | 2 +-
drivers/net/wireless/rtl818x/rtl8187.h | 1 +
drivers/net/wireless/rtl818x/rtl8187_dev.c | 28 ++++++-----
drivers/net/wireless/rtl818x/rtl8187_leds.c | 4 +-
drivers/net/wireless/rtl818x/rtl8187_rfkill.c | 63 +++++++++++++++++++++++++
drivers/net/wireless/rtl818x/rtl8187_rfkill.h | 8 +++
drivers/net/wireless/rtl818x/rtl818x.h | 5 +-
7 files changed, 94 insertions(+), 17 deletions(-)
create mode 100644 drivers/net/wireless/rtl818x/rtl8187_rfkill.c
create mode 100644 drivers/net/wireless/rtl818x/rtl8187_rfkill.h
diff --git a/drivers/net/wireless/rtl818x/Makefile b/drivers/net/wireless/rtl818x/Makefile
index 37e3d4d..93cbfbe 100644
--- a/drivers/net/wireless/rtl818x/Makefile
+++ b/drivers/net/wireless/rtl818x/Makefile
@@ -1,5 +1,5 @@
rtl8180-objs := rtl8180_dev.o rtl8180_rtl8225.o rtl8180_sa2400.o rtl8180_max2820.o rtl8180_grf5101.o
-rtl8187-objs := rtl8187_dev.o rtl8187_rtl8225.o rtl8187_leds.o
+rtl8187-objs := rtl8187_dev.o rtl8187_rtl8225.o rtl8187_leds.o rtl8187_rfkill.o
obj-$(CONFIG_RTL8180) += rtl8180.o
obj-$(CONFIG_RTL8187) += rtl8187.o
diff --git a/drivers/net/wireless/rtl818x/rtl8187.h b/drivers/net/wireless/rtl818x/rtl8187.h
index c09bfef..bf9175a 100644
--- a/drivers/net/wireless/rtl818x/rtl8187.h
+++ b/drivers/net/wireless/rtl818x/rtl8187.h
@@ -133,6 +133,7 @@ struct rtl8187_priv {
__le16 bits16;
__le32 bits32;
} *io_dmabuf;
+ bool rfkill_off;
};
void rtl8187_write_phy(struct ieee80211_hw *dev, u8 addr, u32 data);
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index 5830f6c..b6e9fbd 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -32,6 +32,7 @@
#ifdef CONFIG_RTL8187_LEDS
#include "rtl8187_leds.h"
#endif
+#include "rtl8187_rfkill.h"
MODULE_AUTHOR("Michael Wu <flamingice@sourmilk.net>");
MODULE_AUTHOR("Andrea Merello <andreamrl@tiscali.it>");
@@ -648,10 +649,10 @@ static int rtl8187_init_hw(struct ieee80211_hw *dev)
/* setup card */
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, 0);
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0);
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, (4 << 8));
- rtl818x_iowrite8(priv, &priv->map->GPIO, 1);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 1);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
@@ -674,11 +675,11 @@ static int rtl8187_init_hw(struct ieee80211_hw *dev)
/* host_usb_init */
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, 0);
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0);
reg = rtl818x_ioread8(priv, (u8 *)0xFE53);
rtl818x_iowrite8(priv, (u8 *)0xFE53, reg | (1 << 7));
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, (4 << 8));
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0x20);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0x20);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0);
rtl818x_iowrite16(priv, &priv->map->RFPinsOutput, 0x80);
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, 0x80);
@@ -910,12 +911,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
u32 reg;
int ret;
+ mutex_lock(&priv->conf_mutex);
+
ret = (!priv->is_rtl8187b) ? rtl8187_init_hw(dev) :
rtl8187b_init_hw(dev);
if (ret)
- return ret;
-
- mutex_lock(&priv->conf_mutex);
+ goto rtl8187_start_exit;
init_usb_anchor(&priv->anchored);
priv->dev = dev;
@@ -942,8 +943,7 @@ static int rtl8187_start(struct ieee80211_hw *dev)
(7 << 21 /* MAX TX DMA */));
rtl8187_init_urbs(dev);
rtl8187b_init_status_urb(dev);
- mutex_unlock(&priv->conf_mutex);
- return 0;
+ goto rtl8187_start_exit;
}
rtl818x_iowrite16(priv, &priv->map->INT_MASK, 0xFFFF);
@@ -987,9 +987,10 @@ static int rtl8187_start(struct ieee80211_hw *dev)
reg |= RTL818X_CMD_RX_ENABLE;
rtl818x_iowrite8(priv, &priv->map->CMD, reg);
INIT_DELAYED_WORK(&priv->work, rtl8187_work);
- mutex_unlock(&priv->conf_mutex);
- return 0;
+rtl8187_start_exit:
+ mutex_unlock(&priv->conf_mutex);
+ return ret;
}
static void rtl8187_stop(struct ieee80211_hw *dev)
@@ -1282,7 +1283,8 @@ static const struct ieee80211_ops rtl8187_ops = {
.bss_info_changed = rtl8187_bss_info_changed,
.prepare_multicast = rtl8187_prepare_multicast,
.configure_filter = rtl8187_configure_filter,
- .conf_tx = rtl8187_conf_tx
+ .conf_tx = rtl8187_conf_tx,
+ .rfkill_poll = rtl8187_rfkill_poll
};
static void rtl8187_eeprom_register_read(struct eeprom_93cx6 *eeprom)
@@ -1522,6 +1524,7 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
reg &= 0xFF;
rtl8187_leds_init(dev, reg);
#endif
+ rtl8187_rfkill_init(dev);
return 0;
@@ -1545,6 +1548,7 @@ static void __devexit rtl8187_disconnect(struct usb_interface *intf)
#ifdef CONFIG_RTL8187_LEDS
rtl8187_leds_exit(dev);
#endif
+ rtl8187_rfkill_exit(dev);
ieee80211_unregister_hw(dev);
priv = dev->priv;
diff --git a/drivers/net/wireless/rtl818x/rtl8187_leds.c b/drivers/net/wireless/rtl818x/rtl8187_leds.c
index a6cfb7e..a1c670f 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -42,7 +42,7 @@ static void led_turn_on(struct work_struct *work)
mutex_lock(&priv->conf_mutex);
switch (led->ledpin) {
case LED_PIN_GPIO0:
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0x01);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0x01);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0x00);
break;
case LED_PIN_LED0:
@@ -80,7 +80,7 @@ static void led_turn_off(struct work_struct *work)
mutex_lock(&priv->conf_mutex);
switch (led->ledpin) {
case LED_PIN_GPIO0:
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0x01);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0x01);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0x01);
break;
case LED_PIN_LED0:
diff --git a/drivers/net/wireless/rtl818x/rtl8187_rfkill.c b/drivers/net/wireless/rtl818x/rtl8187_rfkill.c
new file mode 100644
index 0000000..1e17236
--- /dev/null
+++ b/drivers/net/wireless/rtl818x/rtl8187_rfkill.c
@@ -0,0 +1,63 @@
+/*
+ * Linux RFKILL support for RTL8187B
+ *
+ * Copyright (c) 2009 Herton Ronaldo Krzesinski <herton@mandriva.com.br>
+ *
+ * Based on the RFKILL handling in the r8187 driver, which is:
+ * Copyright (c) Realtek Semiconductor Corp. All rights reserved.
+ *
+ * Thanks to Realtek for their support!
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/types.h>
+#include <linux/usb.h>
+#include <net/mac80211.h>
+
+#include "rtl8187.h"
+
+static bool rtl8187_is_radio_enabled(struct rtl8187_priv *priv)
+{
+ u8 gpio;
+
+ gpio = rtl818x_ioread8(priv, &priv->map->GPIO0);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, gpio & ~0x02);
+ gpio = rtl818x_ioread8(priv, &priv->map->GPIO1);
+
+ return gpio & 0x02;
+}
+
+void rtl8187_rfkill_init(struct ieee80211_hw *hw)
+{
+ struct rtl8187_priv *priv = hw->priv;
+
+ priv->rfkill_off = rtl8187_is_radio_enabled(priv);
+ printk(KERN_INFO "rtl8187: wireless switch is %s\n",
+ priv->rfkill_off ? "on" : "off");
+ wiphy_rfkill_set_hw_state(hw->wiphy, !priv->rfkill_off);
+ wiphy_rfkill_start_polling(hw->wiphy);
+}
+
+void rtl8187_rfkill_poll(struct ieee80211_hw *hw)
+{
+ bool enabled;
+ struct rtl8187_priv *priv = hw->priv;
+
+ mutex_lock(&priv->conf_mutex);
+ enabled = rtl8187_is_radio_enabled(priv);
+ if (unlikely(enabled != priv->rfkill_off)) {
+ priv->rfkill_off = enabled;
+ printk(KERN_INFO "rtl8187: wireless radio switch turned %s\n",
+ enabled ? "on" : "off");
+ wiphy_rfkill_set_hw_state(hw->wiphy, !enabled);
+ }
+ mutex_unlock(&priv->conf_mutex);
+}
+
+void rtl8187_rfkill_exit(struct ieee80211_hw *hw)
+{
+ wiphy_rfkill_stop_polling(hw->wiphy);
+}
diff --git a/drivers/net/wireless/rtl818x/rtl8187_rfkill.h b/drivers/net/wireless/rtl818x/rtl8187_rfkill.h
new file mode 100644
index 0000000..e12575e
--- /dev/null
+++ b/drivers/net/wireless/rtl818x/rtl8187_rfkill.h
@@ -0,0 +1,8 @@
+#ifndef RTL8187_RFKILL_H
+#define RTL8187_RFKILL_H
+
+void rtl8187_rfkill_init(struct ieee80211_hw *hw);
+void rtl8187_rfkill_poll(struct ieee80211_hw *hw);
+void rtl8187_rfkill_exit(struct ieee80211_hw *hw);
+
+#endif /* RTL8187_RFKILL_H */
diff --git a/drivers/net/wireless/rtl818x/rtl818x.h b/drivers/net/wireless/rtl818x/rtl818x.h
index 562222e..8522490 100644
--- a/drivers/net/wireless/rtl818x/rtl818x.h
+++ b/drivers/net/wireless/rtl818x/rtl818x.h
@@ -138,8 +138,9 @@ struct rtl818x_csr {
__le32 RF_PARA;
__le32 RF_TIMING;
u8 GP_ENABLE;
- u8 GPIO;
- u8 reserved_12[2];
+ u8 GPIO0;
+ u8 GPIO1;
+ u8 reserved_12;
__le32 HSSI_PARA;
u8 reserved_13[4];
u8 TX_AGC_CTL;
--
1.6.4
^ permalink raw reply related
* Re: Plans for an online meeting regarding Radiotap
From: Dave Young @ 2009-08-22 4:38 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Johannes Berg, Richard Farina, Mike Kershaw, Sam Leffler,
Rafael Laufer, Damien Bergamini, Sepherosa Ziehau,
Thomas d'Otreppe, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <69e28c910908211455u5dcd70f0u94eab510ab91a69a@mail.gmail.com>
2009/8/22 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
>> On Fri, 2009-08-21 at 17:04 +0200, Gábor Stefanik wrote:
>>
>>> I've reworked RTS/CTS since then, just haven't got to sending a new
>>> proposal yet. The current plan is as follows:
>>>
>>> TX_FLAGS & 0x0002: Use CTS
>>> TX_FLAGS & 0x0004: Use RTS
>>> TX_FLAGS & 0x0020: Disable RTS/CTS usage
>>
>> Seems a bit strange, wouldn't setting neither RTS nor CTS have the
>> effect? Seems like 0x20 should rather be "use automatic and ignore the
>> other bits". Anyway, not appropriate here, you should just bring a new
>> proposal.
>
> The point is that if all bits are 0, auto-setup is used. The problem
> with my original proposal (using two bits) was that an all-zero value
> had different effect than not including the TX flags field (and simply
> swapping "none" and "auto" would result in an illogicality where what
> would logically be "use both" would become "use neither" - just the
> opposite of its logical meaning). Making 0x20 mean "Auto-select
> RTS/CTS", interpreting all-zeros as "Use neither", would have the same
> problem as my proposal - all-zeros is different from a missing field.
> (An empty, zeroed field 15 should have no effect on the process,
> behaving as if field 15 was not present in the header.)
>
>>
>>> If I remember correctly, I made an implementation for the Linux kernel
>>> (a generator-side implementation) and one for Wireshark (a parser-side
>>> implementation). Or should I make two generator-side implementations
>>> according to the requirement (e.g. one for Linux, another for
>>> OpenBSD)?
>>
>> No, that was ok, I just meant that therefore by definition it can't be a
>> problem of lack of implementations.
>>
>> johannes
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
Here also, please fix your cc-list, I'm not the david what you want to send to
--
Regards
dave
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-22 5:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, linux-wireless
In-Reply-To: <1250858409.5137.2.camel@johannes.local>
Instead of waiting for the codes, we decide to do someting on
supporting the BCM 4325 running in linux via SDIO.
The linux wireless dirver supports another chip (marvel 8686) with
SDIO interface, the sources codes locate in
drivers/net/wireless/libertas.
We are wondering to develop the BCM4325 driver in the reference to the
marvel 8686 SDIO driver.
Please give comments on this, thanks.
BR
Feng
2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2009-08-21 at 07:13 -0500, Larry Finger wrote:
>
>> > We are working on a project which supports the BCM4325 linux wireless
>> > driver. The interface between the BCM chip and SOC(pxa310) is SDIO.
>> > I did some searches online and found that there is no available driver
>> > for this chip. Do I have to implement this myself? Is there anyone can
>> > provide us some related materials? Thanks very much.
>>
>> The code for the LP PHY, which I believe is present in the 4325, is
>> just being written. At the moment, the chip is able to receive on some
>> channels, and may be able to transmit. These results are reported on
>> this mailing list, and the code is being applied to the wireless
>> testing git tree.
>
> Also, somebody is working on SDIO support with Michael.
>
> johannes
>
^ permalink raw reply
* Re: [PATCH] mac80211 : fix a race with update_tkip_key
From: Johannes Berg @ 2009-08-22 7:45 UTC (permalink / raw)
To: gregor kowski; +Cc: linux-wireless
In-Reply-To: <83a869cd0908211513k2e14ba40k251aa8a1e7393a77@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Sat, 2009-08-22 at 00:13 +0200, gregor kowski wrote:
> The mac80211 tkip code won't call update_tkip_key, if some rx packets
s/,// s/rx //
> get received without KEY_FLAG_UPLOADED_TO_HARDWARE. This can happen on
s/get/are/
> first packet because the hardware key stuff is called asynchronously with
> todo workqueue.
>
> This patch workaround that by tracking if we send the key to hardware.
s/send/sent/, s/hardware/the driver/
> +enum ieee80211_internal_tkip_initialized {
> + TKIP_INITIALIZED_NONE,
> + TKIP_INITIALIZED_PHASE1,
> + TKIP_INITIALIZED_UPDATE_KEY,
> +};
Those constants and the enum itself really need better names. This way,
there's no way to understand what it means without reading all the code.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Johannes Berg @ 2009-08-22 7:48 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4A8EE182.6040709@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]
On Fri, 2009-08-21 at 11:03 -0700, Rafael Laufer wrote:
> + * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
> + * used to indicate that the rate was defined in the received radiotap
> + * header and therefore the rate control algorithm should not change it.
This should be an internal flag, the driver doesn't care.
> + /* In monitor mode, if the IEEE80211_RADIOTAP_RATE option is set in
> + * the received radiotap header, do not call the rate control algorithm.
> + */
coding style
> + /* Get the rate parameter from the radiotap header,
> + * allowing rate selection on a per-packet basis
> + */
coding style
> + case IEEE80211_RADIOTAP_RATE:
> + bitrate = (*iterator.this_arg) * 5;
> + for (i = 0; i < sband->n_bitrates; i++) {
> + if (sband->bitrates[i].bitrate == bitrate)
> + break;
> + }
> + if (i != sband->n_bitrates) {
> + info->control.rates[0].idx = i;
> + info->flags |= IEEE80211_TX_CTL_RATE_RADIOTAP;
> + }
You never set the counter, or any other fields.
> /*
> * Please update the file
> * Documentation/networking/mac80211-injection.txt
And you even quote the instructions.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Johannes Berg @ 2009-08-22 7:50 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4A8F01B8.40708@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Fri, 2009-08-21 at 13:21 -0700, Rafael Laufer wrote:
> It is strange that a function called "get_rate" would also change other
> fields which are at first sight do not look related to rate. Why not
> call other functions for that? What is the reasoning behind this?
> Different rates have different retry counts or RTS/CTS usage?
I can't tell if you're kidding or not. This also doesn't get a single
rate, but the entire rate control setup.
> As far as I could tell from a quick look in the code,
> rate_control_get_rate only sets the fields of info->control.rates,
> except for this driver-specific function.
Right. And now look again what's in control.rates[].
> If this function really does other stuff, then a simple solution is to
> check if the IEEE80211_TX_CTL_RATE_RADIOTAP flag is set and, in that
> case, store the value of info->control.rates[0].idx before calling
> rate_control_get_rate, and restoring it afterwards. Make sense?
Ick, no.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Johannes Berg @ 2009-08-22 7:52 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John Linville
In-Reply-To: <200908212252.41053.chunkeey@web.de>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Fri, 2009-08-21 at 22:52 +0200, Christian Lamparter wrote:
> Johannes, in phy.c (now at line) line 429
>
> int ar9170_init_phy(struct ar9170 *ar, enum ieee80211_band band)
> {
> [...]
> /* XXX: use EEPROM data here! */
>
> err = ar9170_init_power_cal(ar);
> if (err)
> [...]
> }
>
> do you still know what EEPROM data is missing here?
Sorry, no, I don't remember, and can't seem to find it either in otus
right now.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] compal-laptop: Replace sysfs support with rfkill support
From: Alan Jenkins @ 2009-08-22 11:20 UTC (permalink / raw)
To: Mario Limonciello
Cc: cezary.jackiewicz, linux-wireless, linux-acpi, linux-kernel
In-Reply-To: <1250890778-28959-1-git-send-email-Mario_Limonciello@Dell.com>
On 8/21/09, Mario Limonciello <Mario_Limonciello@dell.com> wrote:
> This drops the support for manually groking the files in sysfs
> to turn on and off the WLAN and BT for Compal laptops in favor
> of platform rfkill support.
>
> It has been combined into a single patch to not introduce regressions
> in the process of simply adding rfkill support.
>
> Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
> @@ -390,23 +314,19 @@ static int __init compal_init(void)
>
> ret = platform_device_add(compal_device);
> if (ret)
> - goto fail_platform_device1;
> + goto fail_platform_device;
>
> - ret = sysfs_create_group(&compal_device->dev.kobj,
> - &compal_attribute_group);
> + ret = setup_rfkill();
> if (ret)
> - goto fail_platform_device2;
> + goto fail_rfkill;
>
> printk(KERN_INFO "compal-laptop: driver "COMPAL_DRIVER_VERSION
> " successfully loaded.\n");
>
> return 0;
>
> -fail_platform_device2:
> -
> - platform_device_del(compal_device);
> -
> -fail_platform_device1:
> +fail_rfkill:
> +fail_platform_device:
>
> platform_device_put(compal_device);
>
I guess our mails crossed. As in the previous patch I think
platform_device_del() should still be called, in the fail_rfkill case.
Previously platform_device_del() was required after
platform_device_add(), if we bailed out because of a failure in
sysfs_create_group(). I don't think that requirement is removed by
replacing sysfs_create_group() with setup_rfkill().
Regards
Alan
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Bob Copeland @ 2009-08-22 12:47 UTC (permalink / raw)
To: Fabio Comolli; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b6c5339f0908210719o2323d590w4a9f6a01d5ecb2d6@mail.gmail.com>
On Fri, Aug 21, 2009 at 10:19:33AM -0400, Bob Copeland wrote:
> Okay, I think I see what is going on here.
Well I can't quite convince myself of what exactly is requeing
sta work; we do cancel everything already as far as I can tell, but
something is rearming, I just can't tell which.
Fabio, can you please apply this patch against wireless-testing (not
compat-wireless) and report all the warnings produced when doing a
suspend/resume? This should tell us the code paths that are queuing
work too late.
>From 6eb7d5c3ae8f2f42b164491acd02631858515876 Mon Sep 17 00:00:00 2001
From: Bob Copeland <me@bobcopeland.com>
Date: Sat, 22 Aug 2009 08:40:53 -0400
Subject: [PATCH] mac80211: set suspended before final flush_workqueue
Just a temporary debugging aid.
---
net/mac80211/pm.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index a5d2f1f..231c8be 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -117,13 +117,13 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
* shouldn't be doing (or cancel everything in the
* stop callback) that but better safe than sorry.
*/
- flush_workqueue(local->workqueue);
-
local->suspended = true;
/* need suspended to be visible before quiescing is false */
barrier();
local->quiescing = false;
+ flush_workqueue(local->workqueue);
+
return 0;
}
--
1.6.2.5
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply related
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Fabio Comolli @ 2009-08-22 13:02 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <20090822124709.GA6762@hash.localnet>
Hi Bob.
On Sat, Aug 22, 2009 at 2:47 PM, Bob Copeland<me@bobcopeland.com> wrote:
> On Fri, Aug 21, 2009 at 10:19:33AM -0400, Bob Copeland wrote:
>> Okay, I think I see what is going on here.
>
> Well I can't quite convince myself of what exactly is requeing
> sta work; we do cancel everything already as far as I can tell, but
> something is rearming, I just can't tell which.
>
> Fabio, can you please apply this patch against wireless-testing (not
> compat-wireless) and report all the warnings produced when doing a
> suspend/resume? This should tell us the code paths that are queuing
> work too late.
I'm not a git user. How can I user wireless-testing without git? Is
there a patch or seomething?
>
> From 6eb7d5c3ae8f2f42b164491acd02631858515876 Mon Sep 17 00:00:00 2001
> From: Bob Copeland <me@bobcopeland.com>
> Date: Sat, 22 Aug 2009 08:40:53 -0400
> Subject: [PATCH] mac80211: set suspended before final flush_workqueue
>
> Just a temporary debugging aid.
> ---
> net/mac80211/pm.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
> index a5d2f1f..231c8be 100644
> --- a/net/mac80211/pm.c
> +++ b/net/mac80211/pm.c
> @@ -117,13 +117,13 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
> * shouldn't be doing (or cancel everything in the
> * stop callback) that but better safe than sorry.
> */
> - flush_workqueue(local->workqueue);
> -
> local->suspended = true;
> /* need suspended to be visible before quiescing is false */
> barrier();
> local->quiescing = false;
>
> + flush_workqueue(local->workqueue);
> +
> return 0;
> }
>
> --
> 1.6.2.5
>
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
Regards,
Fabio
^ 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