* BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
From: Justin Mattock @ 2010-06-22 23:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Linux Kernel Mailing List
I remember ipsec was able to work cleanly on my machines probably
about 4/6 months ago
now I get this:
[ 302.071077] BUG: unable to handle kernel NULL pointer dereference
at 00000000000000a0
[ 302.071084] IP: [<ffffffff81387e0b>] xfrm_bundle_ok+0x14f/0x2e9
[ 302.071094] PGD 13e695067 PUD 139c7e067 PMD 0
[ 302.071100] Oops: 0000 [#1] SMP
[ 302.071104] last sysfs file:
/sys/devices/pci0000:00/0000:00:15.0/0000:04:00.0/net/eth1/statistics/tx_bytes
[ 302.071109] CPU 0
[ 302.071111] Modules linked in: xfrm4_mode_transport sco xcbc bnep
rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state
nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4
iptable_filter ip_tables x_tables firewire_ohci firewire_core evdev
lib80211_crypt_tkip uvcvideo videodev ohci1394 v4l1_compat button
thermal wl(P) nvidia(P) ohci_hcd forcedeth i2c_nforce2 aes_x86_64 lzo
lzo_compress ipcomp xfrm_ipcomp crypto_null sha256_generic cbc
des_generic cast5 blowfish serpent camellia twofish twofish_common ctr
ah4 esp4 authenc adm1021 raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart
rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor
mperf appletouch applesmc
[ 302.071185]
[ 302.071189] Pid: 2603, comm: vncviewer Tainted: P
2.6.35-rc2-00001-g8dd40f7 #3 Mac-F2218FC8/iMac9,1
[ 302.071193] RIP: 0010:[<ffffffff81387e0b>] [<ffffffff81387e0b>]
xfrm_bundle_ok+0x14f/0x2e9
[ 302.071199] RSP: 0018:ffff880139f4db58 EFLAGS: 00010246
[ 302.071202] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 302.071206] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880139f48700
[ 302.071209] RBP: ffff880139f4dbc8 R08: 0000000000000000 R09: ffff8801389cc574
[ 302.071212] R10: dead000000200200 R11: ffff880139f4dc98 R12: ffff88012739a500
[ 302.071216] R13: ffff88012739a780 R14: 0000000000000000 R15: ffff88012ed266c0
[ 302.071220] FS: 00007f201be85740(0000) GS:ffff880001a00000(0000)
knlGS:0000000000000000
[ 302.071224] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 302.071227] CR2: 00000000000000a0 CR3: 000000013b2a6000 CR4: 00000000000406f0
[ 302.071230] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 302.071234] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 302.071238] Process vncviewer (pid: 2603, threadinfo
ffff880139f4c000, task ffff880131b1dc40)
[ 302.071240] Stack:
[ 302.071242] ffff8801389366c0 ffffffff8168ff08 000000000000001c
000000000000000c
[ 302.071248] <0> 0000000000000000 00000000004623c0 0000000000000000
0000000081606c40
[ 302.071253] <0> ffff8801389cc480 ffff88012739a500 ffff88012ef80780
0000000000000000
[ 302.071260] Call Trace:
[ 302.071265] [<ffffffff81387fba>] stale_bundle+0x15/0x1f
[ 302.071270] [<ffffffff81387fdc>] xfrm_dst_check+0x18/0x2e
[ 302.071275] [<ffffffff8131d02f>] __sk_dst_check+0x27/0x53
[ 302.071281] [<ffffffff8135172a>] ip_queue_xmit+0x3c/0x2ed
[ 302.071286] [<ffffffff8136405c>] ? tcp_connect+0x1d4/0x379
[ 302.071290] [<ffffffff8131eef3>] ? __skb_clone+0x29/0x100
[ 302.071295] [<ffffffff81363dc0>] tcp_transmit_skb+0x6e1/0x71f
[ 302.071300] [<ffffffff81364175>] tcp_connect+0x2ed/0x379
[ 302.071305] [<ffffffff81243739>] ? secure_tcp_sequence_number+0x55/0x6e
[ 302.071310] [<ffffffff813692ee>] tcp_v4_connect+0x3c4/0x419
[ 302.071316] [<ffffffff811952d2>] ? avc_has_perm+0x57/0x69
[ 302.071321] [<ffffffff81375030>] inet_stream_connect+0xa7/0x260
[ 302.071326] [<ffffffff8131aa26>] sys_connect+0x75/0x9b
[ 302.071332] [<ffffffff810e403c>] ? fd_install+0x52/0x5b
[ 302.071338] [<ffffffff81092983>] ? audit_syscall_entry+0x1b6/0x1e2
[ 302.071342] [<ffffffff8131a552>] ? sys_socket+0x3b/0x57
[ 302.071348] [<ffffffff81025f42>] system_call_fastpath+0x16/0x1b
[ 302.071350] Code: 7d 58 41 80 bf c0 00 00 00 02 0f 85 98 01 00 00
41 8b 87 a8 00 00 00 41 39 85 b8 01 00 00 0f 85 84 01 00 00 49 8b 85
90 01 00 00 <8b> 80 a0 00 00 00 41 39 85 bc 01 00 00 0f 85 6a 01 00 00
83 7d
[ 302.071400] RIP [<ffffffff81387e0b>] xfrm_bundle_ok+0x14f/0x2e9
[ 302.071405] RSP <ffff880139f4db58>
[ 302.071408] CR2: 00000000000000a0
[ 302.071414] ---[ end trace b4323dbb88295950 ]---
starting a bisect, but might take some time....
--
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 2/2] wl1251: fix ELP_CTRL register reads
From: Denis 'GNUtoo' Carikli @ 2010-06-22 23:33 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Bob Copeland, Kalle Valo, John W.Linville, linux-wireless
In-Reply-To: <AANLkTildbagKqzTQbcZ8cT53s4L2OWpJ5fkBUTcejj0h@mail.gmail.com>
On Tue, 2010-06-22 at 01:48 +0300, Grazvydas Ignotas wrote:
> >> Probably not relevant to power saving, but:
> >>
> >> Are you using the dedicated irq line or sdio interrupt?
> >> It makes a big difference in overall throughput to use
> >> the former.
> > I don't know. what should I grep for?
>
> It might actually be related.. Try adding this to your board file to
> enable GPIO irq:
>
> static void wl1251_set_power(bool enable)
> {
> }
>
> static struct wl12xx_platform_data wl1251_pdata = {
> .set_power = wl1251_set_power,
> };
>
> static struct platform_device wl1251_data = {
> .name = "wl1251_data",
> .id = -1,
> .dev = {
> .platform_data = &wl1251_pdata,
> },
> };
>
> .. then from some init function:
>
> // WIFI_IRQ_GPIO is the GPIO number connected to wl1251 irq line
> wl1251_pdata.irq = gpio_to_irq(WIFI_IRQ_GPIO);
> platform_device_register(&wl1251_pdata);
Thanks a lot for the infos,they were really helpfull.
I've applied that patch(as it was not for submitting,just for reading I
didn't bother sending with git-send-email):
Index: sources/arch/arm/mach-msm/board-trout.c
===================================================================
--- sources.orig/arch/arm/mach-msm/board-trout.c 2010-06-23
00:41:54.601288614 +0200
+++ sources/arch/arm/mach-msm/board-trout.c 2010-06-23
00:43:59.893158944 +0200
@@ -52,6 +52,7 @@
#include <asm/mach/mmc.h>
#include <linux/mmc/sdio_ids.h>
#include <linux/msm_audio.h>
+#include <linux/spi/wl12xx.h>
#include "board-trout.h"
@@ -363,6 +364,17 @@
},
};
+struct wl12xx_platform_data wl12xx_data = {
+};
+
+static struct platform_device wl12xx = {
+ .name = "wl1251_data",
+ .id = -1,
+ .dev = {
+ .platform_data = &wl12xx_data,
+ },
+};
+
#ifdef CONFIG_HTC_HEADSET
static void h2w_config_cpld(int route)
{
@@ -650,6 +662,7 @@
&trout_pwr_sink,
#endif
&trout_snd,
+ &wl12xx,
};
extern struct sys_timer msm_timer;
@@ -745,6 +758,7 @@
static void __init config_gpios(void)
{
+ wl12xx_data.irq = gpio_to_irq(29);
config_gpio_table(gpio_table, ARRAY_SIZE(gpio_table));
config_camera_off_gpios();
}
Index: sources/include/linux/spi/wl12xx.h
===================================================================
--- sources.orig/include/linux/spi/wl12xx.h 2010-06-23
00:42:03.641283312 +0200
+++ sources/include/linux/spi/wl12xx.h 2010-06-23 00:42:48.103178185
+0200
@@ -26,6 +26,7 @@
struct wl12xx_platform_data {
void (*set_power)(bool enable);
+ int irq;
};
#endif
The patch was made from someone in irc and modified by me later.
Then I load the wifi as usual:
modprobe wl1251_sdio #it doesn't crash
modprobe msm_wifi
the modprobe msm_wifi gives the following result:
[ 1366.500427] wifi probe start
[ 1366.500457] trout_wifi_power: 1
[ 1366.927185] trout_wifi_reset: 0
[ 1367.030944] trout_wifi_set_carddetect: 1
[ 1367.030975] mmc0: card_present 1
[ 1367.030975] mmc0: Slot status change detected (0 -> 1)
[ 1367.031036] wifi probe done
And then I've an invisible crash/kernel panic which result in the
machine lockup and then reboot(so it should be a kernel panic).
Note that I've no serial yet(I think I should really get a serial cable
for this machine)
msm_wifi comes from here:
http://bobcopeland.com/srcs/android/msm_wifi.patch
I had already some wifi structures which may have conflicted:
struct wifi_platform_data trout_wifi_control = {
.set_power = trout_wifi_power,
.set_reset = trout_wifi_reset,
.set_carddetect = trout_wifi_set_carddetect,
#ifdef CONFIG_WIFI_MEM_PREALLOC
.mem_prealloc = trout_wifi_mem_prealloc,
#else
.mem_prealloc = NULL,
#endif
};
static struct platform_device trout_wifi = {
.name = "msm_wifi",
.id = 1,
.num_resources = 0,
.resource = NULL,
.dev = {
.platform_data = &trout_wifi_control,
},
};
Thanks a lot for the help so far.
Denis
^ permalink raw reply
* [PATCH] ath9k: Fix the LED behaviour in idle unassociated state.
From: Vivek Natarajan @ 2010-06-23 6:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
LED should be ON when the radio is put into FULL SLEEP mode during the idle
unassociated state.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 5af2596..c908657 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -829,9 +829,14 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
ath9k_ps_wakeup(sc);
ieee80211_stop_queues(hw);
- /* Disable LED */
- ath9k_hw_set_gpio(ah, ah->led_pin, 1);
- ath9k_hw_cfg_gpio_input(ah, ah->led_pin);
+ /*
+ * Keep the LED on when the radio is disabled
+ * during idle unassociated state.
+ */
+ if (!sc->ps_idle) {
+ ath9k_hw_set_gpio(ah, ah->led_pin, 1);
+ ath9k_hw_cfg_gpio_input(ah, ah->led_pin);
+ }
/* Disable interrupts */
ath9k_hw_set_interrupts(ah, 0);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] Libertas: cfg80211 support
From: Johannes Berg @ 2010-06-23 8:25 UTC (permalink / raw)
To: dkiran; +Cc: linux-wireless
In-Reply-To: <1276533086.18884.9.camel@pe-lt028>
On Mon, 2010-06-14 at 22:01 +0530, Kiran Divekar wrote:
> Holger Schurig's patch (https://patchwork.kernel.org/patch/64286/)
> is rebased to latest wireless-testing tree.
+drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in assignment (different base types)
+drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short [unsigned] [usertype] capability
+drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16 [usertype] <noident>
+drivers/net/wireless/libertas/cmdresp.c:106:5: warning: symbol 'lbs_ret_802_11d_domain_info' was not declared. Should it be static?
I'm guessing this patchset is at fault.
johannes
^ permalink raw reply
* Re: ATH5k - Signal measurement reports wrong values - "calib" did not help
From: Jaroslav Fojtik @ 2010-06-23 9:03 UTC (permalink / raw)
To: linux-wireless; +Cc: bruno Randolf
In-Reply-To: <201006211650.50766.br1@einfach.org>
Dear Bruno & ATH5k developpers,
> > > it might be interresting to see what results you get from noise
> > > calibration. you can enable calibration debugging with "echo calib >
> > > /sys/kernel/debug/ath5k/phy0/debug"
Nothing changed after setting "calib" on.
ATH5k still reports bad values.
You could see a magenta line here:
http://78.108.103.11:11080/cgi-bin/rodga.cgi
regards
Jara
^ permalink raw reply
* 2.6.34 kernel + compat-wireless + Bluez-4.66 --- no Bluetooth devices
From: Andrei Moraru @ 2010-06-23 9:04 UTC (permalink / raw)
To: linux-wireless
Hello,
I have a machine with Centos 5.4, kernel version 2.6.34, Bluez-4.66,
compat-wireless for 2.6.34 kernel version.
The system knows about USB Bluetooth adapters
[root@voip ~]# lsusb
Bus 002 Device 004: ID 1131:1001 Integrated System Solution Corp.
KY-BT100 Bluetooth Adapter
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
However, hciconfig shows no devices:
[root@voip ~]# hciconfig -a
[root@voip ~]#
Also, hcitool dev
[root@voip ~]# hcitool dev
Devices:
the dmesg output about bluetooth shows
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.14
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Please suggest your opinions.
Regards,
Andrei Moraru.
^ permalink raw reply
* [PATCH 2/2] nl80211: Add option to adjust transmit power
From: Juuso Oikarinen @ 2010-06-23 9:12 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1277284358-11014-1-git-send-email-juuso.oikarinen@nokia.com>
This patch adds transmit power setting type and transmit power level attributes
to NL80211_CMD_SET_WIPHY in order to facilitate adjusting of the transmit power
level of the device.
The added attributes allow selection of automatic, limited or fixed transmit
power level, with the level definable in signed mBm format.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/linux/nl80211.h | 9 +++++++++
net/wireless/nl80211.c | 31 +++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 07aa046..2c87016 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -725,6 +725,12 @@ enum nl80211_commands {
* @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
* connected to this BSS.
*
+ * @NL80211_ATTR_WIPHY_TX_POWER_SETTING: Transmit power setting type. See
+ * &enum nl80211_tx_power_setting for possible values.
+ * @NL80211_ATTR_WIPHY_TX_POWER_LEVEL: Transmit power level in signed mBm units.
+ * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
+ * for non-automatic settings.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -882,6 +888,9 @@ enum nl80211_attrs {
NL80211_ATTR_AP_ISOLATE,
+ NL80211_ATTR_WIPHY_TX_POWER_SETTING,
+ NL80211_ATTR_WIPHY_TX_POWER_LEVEL,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 41529ac..a999fc1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -153,6 +153,9 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_CQM] = { .type = NLA_NESTED, },
[NL80211_ATTR_LOCAL_STATE_CHANGE] = { .type = NLA_FLAG },
[NL80211_ATTR_AP_ISOLATE] = { .type = NLA_U8 },
+
+ [NL80211_ATTR_WIPHY_TX_POWER_SETTING] = { .type = NLA_U32 },
+ [NL80211_ATTR_WIPHY_TX_POWER_LEVEL] = { .type = NLA_U32 },
};
/* policy for the attributes */
@@ -869,6 +872,34 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
goto bad_res;
}
+ if (info->attrs[NL80211_ATTR_WIPHY_TX_POWER_SETTING]) {
+ enum nl80211_tx_power_setting type;
+ int idx, mbm = 0;
+
+ if (!rdev->ops->set_tx_power) {
+ return -EOPNOTSUPP;
+ goto bad_res;
+ }
+
+ idx = NL80211_ATTR_WIPHY_TX_POWER_SETTING;
+ type = nla_get_u32(info->attrs[idx]);
+
+ if (!info->attrs[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] &&
+ (type != NL80211_TX_POWER_AUTOMATIC)) {
+ result = -EINVAL;
+ goto bad_res;
+ }
+
+ if (type != NL80211_TX_POWER_AUTOMATIC) {
+ idx = NL80211_ATTR_WIPHY_TX_POWER_LEVEL;
+ mbm = nla_get_u32(info->attrs[idx]);
+ }
+
+ result = rdev->ops->set_tx_power(&rdev->wiphy, type, mbm);
+ if (result)
+ goto bad_res;
+ }
+
changed = 0;
if (info->attrs[NL80211_ATTR_WIPHY_RETRY_SHORT]) {
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] cfg80211/mac80211: Update set_tx_power to use mBm instead of dBm units
From: Juuso Oikarinen @ 2010-06-23 9:12 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In preparation for a TX power setting interface in the nl80211, change the
.set_tx_power function to use mBm units instead of dBm for greater accuracy and
smaller power levels.
Also, already in advance move the tx_power_setting enumeration to nl80211.
This change affects the .tx_set_power function prototype. As a result, the
corresponding changes are needed to modules using it. These are mac80211,
iwmc3200wifi and rndis_wlan.
Cc: Samuel Ortiz <samuel.ortiz@intel.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Acked-by: Samuel Ortiz <samuel.ortiz@intel.com>
Acked-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 12 ++++++++----
drivers/net/wireless/rndis_wlan.c | 20 +++++++++++++-------
include/linux/nl80211.h | 13 +++++++++++++
include/net/cfg80211.h | 15 +--------------
net/mac80211/cfg.c | 22 +++++++++++-----------
net/wireless/wext-compat.c | 10 +++++-----
6 files changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/cfg80211.c b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
index 902e95f..6061967 100644
--- a/drivers/net/wireless/iwmc3200wifi/cfg80211.c
+++ b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
@@ -670,20 +670,24 @@ static int iwm_cfg80211_disconnect(struct wiphy *wiphy, struct net_device *dev,
}
static int iwm_cfg80211_set_txpower(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm)
+ enum nl80211_tx_power_setting type, int mbm)
{
struct iwm_priv *iwm = wiphy_to_iwm(wiphy);
int ret;
switch (type) {
- case TX_POWER_AUTOMATIC:
+ case NL80211_TX_POWER_AUTOMATIC:
return 0;
- case TX_POWER_FIXED:
+ case NL80211_TX_POWER_FIXED:
+ if (mbm < 0 || (mbm % 100))
+ return -EOPNOTSUPP;
+
if (!test_bit(IWM_STATUS_READY, &iwm->status))
return 0;
ret = iwm_umac_set_config_fix(iwm, UMAC_PARAM_TBL_CFG_FIX,
- CFG_TX_PWR_LIMIT_USR, dbm * 2);
+ CFG_TX_PWR_LIMIT_USR,
+ MBM_TO_DBM(mbm) * 2);
if (ret < 0)
return ret;
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 4102cca..5e26edb 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -520,8 +520,9 @@ static int rndis_scan(struct wiphy *wiphy, struct net_device *dev,
static int rndis_set_wiphy_params(struct wiphy *wiphy, u32 changed);
-static int rndis_set_tx_power(struct wiphy *wiphy, enum tx_power_setting type,
- int dbm);
+static int rndis_set_tx_power(struct wiphy *wiphy,
+ enum nl80211_tx_power_setting type,
+ int mbm);
static int rndis_get_tx_power(struct wiphy *wiphy, int *dbm);
static int rndis_connect(struct wiphy *wiphy, struct net_device *dev,
@@ -1856,20 +1857,25 @@ static int rndis_set_wiphy_params(struct wiphy *wiphy, u32 changed)
return 0;
}
-static int rndis_set_tx_power(struct wiphy *wiphy, enum tx_power_setting type,
- int dbm)
+static int rndis_set_tx_power(struct wiphy *wiphy,
+ enum nl80211_tx_power_setting type,
+ int mbm)
{
struct rndis_wlan_private *priv = wiphy_priv(wiphy);
struct usbnet *usbdev = priv->usbdev;
- netdev_dbg(usbdev->net, "%s(): type:0x%x dbm:%i\n",
- __func__, type, dbm);
+ netdev_dbg(usbdev->net, "%s(): type:0x%x mbm:%i\n",
+ __func__, type, mbm);
+
+ if (mbm < 0 || (mbm % 100))
+ return -ENOTSUPP;
/* Device doesn't support changing txpower after initialization, only
* turn off/on radio. Support 'auto' mode and setting same dBm that is
* currently used.
*/
- if (type == TX_POWER_AUTOMATIC || dbm == get_bcm4320_power_dbm(priv)) {
+ if (type == NL80211_TX_POWER_AUTOMATIC ||
+ MBM_TO_DBM(mbm) == get_bcm4320_power_dbm(priv)) {
if (!priv->radio_on)
disassociate(usbdev, true); /* turn on radio */
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 64fb32b..07aa046 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -1659,4 +1659,17 @@ enum nl80211_cqm_rssi_threshold_event {
NL80211_CQM_RSSI_THRESHOLD_EVENT_HIGH,
};
+
+/**
+ * enum nl80211_tx_power_setting - TX power adjustment
+ * @NL80211_TX_POWER_AUTOMATIC: automatically determine transmit power
+ * @NL80211_TX_POWER_LIMITED: limit TX power by the mBm parameter
+ * @NL80211_TX_POWER_FIXED: fix TX power to the mBm parameter
+ */
+enum nl80211_tx_power_setting {
+ NL80211_TX_POWER_AUTOMATIC,
+ NL80211_TX_POWER_LIMITED,
+ NL80211_TX_POWER_FIXED,
+};
+
#endif /* __LINUX_NL80211_H */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 64374f4..9b8b3f4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -875,19 +875,6 @@ enum wiphy_params_flags {
WIPHY_PARAM_COVERAGE_CLASS = 1 << 4,
};
-/**
- * enum tx_power_setting - TX power adjustment
- *
- * @TX_POWER_AUTOMATIC: the dbm parameter is ignored
- * @TX_POWER_LIMITED: limit TX power by the dbm parameter
- * @TX_POWER_FIXED: fix TX power to the dbm parameter
- */
-enum tx_power_setting {
- TX_POWER_AUTOMATIC,
- TX_POWER_LIMITED,
- TX_POWER_FIXED,
-};
-
/*
* cfg80211_bitrate_mask - masks for bitrate control
*/
@@ -1149,7 +1136,7 @@ struct cfg80211_ops {
int (*set_wiphy_params)(struct wiphy *wiphy, u32 changed);
int (*set_tx_power)(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm);
+ enum nl80211_tx_power_setting type, int mbm);
int (*get_tx_power)(struct wiphy *wiphy, int *dbm);
int (*set_wds_peer)(struct wiphy *wiphy, struct net_device *dev,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 003b6ad..f4efbfa 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1329,28 +1329,28 @@ static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
}
static int ieee80211_set_tx_power(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm)
+ enum nl80211_tx_power_setting type, int mbm)
{
struct ieee80211_local *local = wiphy_priv(wiphy);
struct ieee80211_channel *chan = local->hw.conf.channel;
u32 changes = 0;
switch (type) {
- case TX_POWER_AUTOMATIC:
+ case NL80211_TX_POWER_AUTOMATIC:
local->user_power_level = -1;
break;
- case TX_POWER_LIMITED:
- if (dbm < 0)
- return -EINVAL;
- local->user_power_level = dbm;
+ case NL80211_TX_POWER_LIMITED:
+ if (mbm < 0 || (mbm % 100))
+ return -EOPNOTSUPP;
+ local->user_power_level = MBM_TO_DBM(mbm);
break;
- case TX_POWER_FIXED:
- if (dbm < 0)
- return -EINVAL;
+ case NL80211_TX_POWER_FIXED:
+ if (mbm < 0 || (mbm % 100))
+ return -EOPNOTSUPP;
/* TODO: move to cfg80211 when it knows the channel */
- if (dbm > chan->max_power)
+ if (MBM_TO_DBM(mbm) > chan->max_power)
return -EINVAL;
- local->user_power_level = dbm;
+ local->user_power_level = MBM_TO_DBM(mbm);
break;
}
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 9634299..1ff1e9f 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -829,7 +829,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
- enum tx_power_setting type;
+ enum nl80211_tx_power_setting type;
int dbm = 0;
if ((data->txpower.flags & IW_TXPOW_TYPE) != IW_TXPOW_DBM)
@@ -852,7 +852,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
if (data->txpower.value < 0)
return -EINVAL;
dbm = data->txpower.value;
- type = TX_POWER_FIXED;
+ type = NL80211_TX_POWER_FIXED;
/* TODO: do regulatory check! */
} else {
/*
@@ -860,10 +860,10 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
* passed in from userland.
*/
if (data->txpower.value < 0) {
- type = TX_POWER_AUTOMATIC;
+ type = NL80211_TX_POWER_AUTOMATIC;
} else {
dbm = data->txpower.value;
- type = TX_POWER_LIMITED;
+ type = NL80211_TX_POWER_LIMITED;
}
}
} else {
@@ -872,7 +872,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
return 0;
}
- return rdev->ops->set_tx_power(wdev->wiphy, type, dbm);
+ return rdev->ops->set_tx_power(wdev->wiphy, type, DBM_TO_MBM(dbm));
}
EXPORT_SYMBOL_GPL(cfg80211_wext_siwtxpower);
--
1.6.3.3
^ permalink raw reply related
* [PATCH] iw: Add support for setting transmit power level
From: Juuso Oikarinen @ 2010-06-23 9:12 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Add a "set txpower" option to specify the current transmit power level. Modes
supported are automatic, fixed and limited, and the limit may be specified
in signed mBm units.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
nl80211.h | 22 ++++++++++++++++++++++
phy.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/nl80211.h b/nl80211.h
index 64fb32b..2c87016 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -725,6 +725,12 @@ enum nl80211_commands {
* @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
* connected to this BSS.
*
+ * @NL80211_ATTR_WIPHY_TX_POWER_SETTING: Transmit power setting type. See
+ * &enum nl80211_tx_power_setting for possible values.
+ * @NL80211_ATTR_WIPHY_TX_POWER_LEVEL: Transmit power level in signed mBm units.
+ * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
+ * for non-automatic settings.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -882,6 +888,9 @@ enum nl80211_attrs {
NL80211_ATTR_AP_ISOLATE,
+ NL80211_ATTR_WIPHY_TX_POWER_SETTING,
+ NL80211_ATTR_WIPHY_TX_POWER_LEVEL,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -1659,4 +1668,17 @@ enum nl80211_cqm_rssi_threshold_event {
NL80211_CQM_RSSI_THRESHOLD_EVENT_HIGH,
};
+
+/**
+ * enum nl80211_tx_power_setting - TX power adjustment
+ * @NL80211_TX_POWER_AUTOMATIC: automatically determine transmit power
+ * @NL80211_TX_POWER_LIMITED: limit TX power by the mBm parameter
+ * @NL80211_TX_POWER_FIXED: fix TX power to the mBm parameter
+ */
+enum nl80211_tx_power_setting {
+ NL80211_TX_POWER_AUTOMATIC,
+ NL80211_TX_POWER_LIMITED,
+ NL80211_TX_POWER_FIXED,
+};
+
#endif /* __LINUX_NL80211_H */
diff --git a/phy.c b/phy.c
index 8f8d757..f042dc2 100644
--- a/phy.c
+++ b/phy.c
@@ -175,7 +175,7 @@ static int handle_netns(struct nl80211_state *state,
return 1;
NLA_PUT_U32(msg, NL80211_ATTR_PID,
- strtoul(argv[0], &end, 10));
+ strtoul(argv[0], &end, 10));
if (*end != '\0')
return 1;
@@ -258,3 +258,51 @@ COMMAND(set, distance, "<distance>",
NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_distance,
"Set appropriate coverage class for given link distance in meters.\n"
"Valid values: 0 - 114750");
+
+static int handle_txpower(struct nl80211_state *state,
+ struct nl_cb *cb,
+ struct nl_msg *msg,
+ int argc, char **argv)
+{
+ enum nl80211_tx_power_setting type;
+ int ret = -ENOSPC;
+ int mbm;
+
+ /* get the required args */
+ if (argc != 1 && argc != 2)
+ return 1;
+
+ if (!strcmp(argv[0], "auto"))
+ type = NL80211_TX_POWER_AUTOMATIC;
+ else if (!strcmp(argv[0], "fixed"))
+ type = NL80211_TX_POWER_FIXED;
+ else if (!strcmp(argv[0], "limit"))
+ type = NL80211_TX_POWER_LIMITED;
+ else {
+ printf("Invalid parameter: %s\n", argv[0]);
+ return 2;
+ }
+
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_TX_POWER_SETTING, type);
+
+ if (type != NL80211_TX_POWER_AUTOMATIC) {
+ if (argc != 2) {
+ printf("Missing TX power level argument.\n");
+ return 2;
+ }
+
+ mbm = atoi(argv[1]);
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_TX_POWER_LEVEL, mbm);
+ }
+
+ ret = 0;
+
+ nla_put_failure:
+ return ret;
+}
+COMMAND(set, txpower, "<auto|fixed|limit> [<tx power in mBm>]",
+ NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_txpower,
+ "Specify transmit power level and setting type.");
+COMMAND(set, txpower, "<auto|fixed|limit> [<tx power in mBm>]",
+ NL80211_CMD_SET_WIPHY, 0, CIB_NETDEV, handle_txpower,
+ "Specify transmit power level and setting type.");
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 2/2] nl80211: Add option to adjust transmit power
From: Artem Mygaiev @ 2010-06-23 9:26 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1277284358-11014-2-git-send-email-juuso.oikarinen@nokia.com>
Hello Juuso
A very minor comment - why do you need 'idx' here? Can't you just directly
access array by NL80211_* index without adding an index variable?
> + if (info->attrs[NL80211_ATTR_WIPHY_TX_POWER_SETTING]) {
> + enum nl80211_tx_power_setting type;
> + int idx, mbm = 0;
> +
> + if (!rdev->ops->set_tx_power) {
> + return -EOPNOTSUPP;
> + goto bad_res;
> + }
> +
> + idx = NL80211_ATTR_WIPHY_TX_POWER_SETTING;
> + type = nla_get_u32(info->attrs[idx]);
> +
> + if (!info->attrs[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] &&
> + (type != NL80211_TX_POWER_AUTOMATIC)) {
> + result = -EINVAL;
> + goto bad_res;
> + }
> +
> + if (type != NL80211_TX_POWER_AUTOMATIC) {
> + idx = NL80211_ATTR_WIPHY_TX_POWER_LEVEL;
> + mbm = nla_get_u32(info->attrs[idx]);
> + }
> +
> + result = rdev->ops->set_tx_power(&rdev->wiphy, type, mbm);
> + if (result)
> + goto bad_res;
> + }
--
Best regards,
Artem
^ permalink raw reply
* Re: [PATCH 2/2] nl80211: Add option to adjust transmit power
From: Juuso Oikarinen @ 2010-06-23 10:08 UTC (permalink / raw)
To: ext Artem Mygaiev; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <op.veqxtlvunp38ce@conquistador-pc.synapse.com>
Hi Artem,
On Wed, 2010-06-23 at 11:26 +0200, ext Artem Mygaiev wrote:
> Hello Juuso
>
> A very minor comment - why do you need 'idx' here? Can't you just directly
> access array by NL80211_* index without adding an index variable?
The idx is there for pure beautification - there's no way to decently
fit onto one line without it ;)
-Juuso
>
> > + if (info->attrs[NL80211_ATTR_WIPHY_TX_POWER_SETTING]) {
> > + enum nl80211_tx_power_setting type;
> > + int idx, mbm = 0;
> > +
> > + if (!rdev->ops->set_tx_power) {
> > + return -EOPNOTSUPP;
> > + goto bad_res;
> > + }
> > +
> > + idx = NL80211_ATTR_WIPHY_TX_POWER_SETTING;
> > + type = nla_get_u32(info->attrs[idx]);
> > +
> > + if (!info->attrs[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] &&
> > + (type != NL80211_TX_POWER_AUTOMATIC)) {
> > + result = -EINVAL;
> > + goto bad_res;
> > + }
> > +
> > + if (type != NL80211_TX_POWER_AUTOMATIC) {
> > + idx = NL80211_ATTR_WIPHY_TX_POWER_LEVEL;
> > + mbm = nla_get_u32(info->attrs[idx]);
> > + }
> > +
> > + result = rdev->ops->set_tx_power(&rdev->wiphy, type, mbm);
> > + if (result)
> > + goto bad_res;
> > + }
>
^ permalink raw reply
* [PATCH] rt2500usb: fallback to SW encryption for TKIP+AES
From: Ondrej Zary @ 2010-06-23 10:57 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <201006222346.06150.linux@rainbow-software.org>
On Tuesday 22 June 2010, Ondrej Zary wrote:
> On Tuesday 22 June 2010 21:35:18 Gertjan van Wingerde wrote:
> > On 06/22/10 12:38, Ondrej Zary wrote:
> > > Hello,
> > > I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
> > > 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink
> > > RT2500USB]
> > >
> > > The problem only appears when HW encryption is enabled and connecting
> > > to an AP configured as WPA2 TKIP+AES.
> > >
> > > HW encryption works when the AP is configured as TKIP-only or AES-only.
> > > It also works when AP is configured as TKIP+AES but wpa_supplicant is
> > > forced to use TKIP as pairwise cipher (pairwise=TKIP)
> > >
> > > SW encryption works always.
> > >
> > > The problem is that no packets are transmitted. I can't see DHCP
> > > broadcasts on other machine using tcpdump. But when I run tcpdump on
> > > the rt2500usb, I see broadcasts from the other machine, so receive
> > > seems to work fine.
> > >
> > > Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
> > > [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
> > > [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
> > > [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
> > > [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.274533] wlan1: authenticated
> > > [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
> > > [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411
> > > status=0 aid=1) [ 373.277704] wlan1: associated
> > > [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
> > > hw_key_idx = 0 OK [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
> > > [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
> > > hw_key_idx = 1 OK [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
> > > [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 375.160246] rt2x00crypto_tx_overhead=8
> > > [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
> > > [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
> > > [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 381.163507] rt2x00crypto_tx_overhead=8
> > > [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
> > > [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
> > > [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 388.165194] rt2x00crypto_tx_overhead=8
> > > [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
> > > [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
> > > [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 399.169481] rt2x00crypto_tx_overhead=8
> > > [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
> > > [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
> > > [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
> > > [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
> > > [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 410.168850] rt2x00crypto_tx_overhead=8
> > > [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
> > > [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
> > > [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
> > > [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
> > > [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 422.169699] rt2x00crypto_tx_overhead=8
> > > [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
> > > [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
> > >
> > > Seems that it's trying to use CCMP, which is good. I wonder if the keys
> > > are properly handled in rt2500usb_config_key. They seem to be uploaded
> > > to the HW correctly (one at index 0, one at 1) - but can't tell without
> > > any HW docs.
> > >
> > > I did some framedumps before but don't know what to do with them (what
> > > to look for):
> > > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> > > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.tx
> > >t
> > >
> > > Anything else I can try?
> >
> > Hi Ondrej,
> >
> > Did you also test what happens if you configure the AP to be TKIP+AES and
> > force wpa-supplicant to use AES pairwise key?
> > If my analysis below is correct then that may work as well.
>
> That does not work - it's probably the same case as default options (TKIP
> group key + AES pairwise key).
>
> > If my reading of the rt2570 data sheet is correct, then the rt2570 will
> > only support one encryption mechanism at the time. That means that it is
> > not possible to upload 1 TKIP key and 1 AES key at the same time to the
> > hardware. All the configured keys have to be of the same encryption
> > algorithm.
> > Presumably this is why the HW encryption engine fails, as the keys are
> > set with mixed settings.
> > Based on that, I don't think that rt2500usb can support this TKIP+AES
> > setting on wpa-supplicant.
>
> If this is true, then the driver should fall back to SW encryption in this
> case.
HW crypto in rt2500usb does not seem to support keys with different ciphers,
which breaks TKIP+AES mode. Fall back to software encryption to fix it.
This should fix long-standing problems with rt2500usb and WPA, such as:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
https://bugzilla.redhat.com/show_bug.cgi?id=484888
Also tested that it does not break WEP, TKIP-only and AES-only modes.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
diff -urp linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c
--- linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-12 04:14:04.000000000 +0200
+++ linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-23 12:18:43.000000000 +0200
@@ -348,6 +348,7 @@ static int rt2500usb_config_key(struct r
int timeout;
u32 mask;
u16 reg;
+ enum cipher curr_cipher;
if (crypto->cmd == SET_KEY) {
/*
@@ -358,6 +359,7 @@ static int rt2500usb_config_key(struct r
mask = TXRX_CSR0_KEY_ID.bit_mask;
rt2500usb_register_read(rt2x00dev, TXRX_CSR0, ®);
+ curr_cipher = rt2x00_get_field16(reg, TXRX_CSR0_ALGORITHM);
reg &= mask;
if (reg && reg == mask)
@@ -366,6 +368,14 @@ static int rt2500usb_config_key(struct r
reg = rt2x00_get_field16(reg, TXRX_CSR0_KEY_ID);
key->hw_key_idx += reg ? ffz(reg) : 0;
+ /*
+ * Hardware requires that all keys use the same cipher
+ * (e.g. TKIP-only, AES-only, but not TKIP+AES).
+ * If this is not the first key, compare the cipher with the
+ * first one and fall back to SW crypto if not the same.
+ */
+ if (key->hw_key_idx > 0 && crypto->cipher != curr_cipher)
+ return -EOPNOTSUPP;
/*
* The encryption key doesn't fit within the CSR cache,
--
Ondrej Zary
^ permalink raw reply
* Re: Recent results with BCM4312 on Netbook
From: Michael Büsch @ 2010-06-23 12:42 UTC (permalink / raw)
To: Larry Finger; +Cc: Gábor Stefanik, wireless, b43-dev
In-Reply-To: <AANLkTikjzHcT9L472CFJ2LKtOiEUIk2S78_S_s-IxHjl@mail.gmail.com>
Please note that there were some rewrites recently in the kernel
DMA subsystem. b43 does now use the generic DMA interface, which
should work on all busses. I would not rule out an error in
that area, though it's unlikely.
--
Greetings Michael.
^ permalink raw reply
* [PATCH] ath9k: Fix bug in starting ani
From: Vasanthakumar Thiagarajan @ 2010-06-23 13:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
There are few places where ANI is started without checking
if it is right to start. This might lead to a case where ani
timer would be left undeleted and cause improper memory acccess
during module unload. This bug is clearly exposed with
paprd support where the driver detects tx hang and does a
chip reset. During this reset ani is (re)started without checking
if it needs to be started. This would leave a timer scheduled
even after all the resources are freed and cause a panic.
This patch introduces a bit in sc_flags to indicate if ani
needs to be started in sw_scan_start() and ath_reset().
This would fix the following panic. This issue is easily seen
with ar9003 + paprd.
BUG: unable to handle kernel paging request at 0000000000003f38
[<ffffffff81075391>] ? __queue_work+0x41/0x50
[<ffffffff8106afaa>] run_timer_softirq+0x17a/0x370
[<ffffffff81088be8>] ? tick_dev_program_event+0x48/0x110
[<ffffffff81061f69>] __do_softirq+0xb9/0x1f0
[<ffffffff810ba060>] ? handle_IRQ_event+0x50/0x160
[<ffffffff8100af5c>] call_softirq+0x1c/0x30
[<ffffffff8100c9f5>] do_softirq+0x65/0xa0
[<ffffffff81061e25>] irq_exit+0x85/0x90
[<ffffffff8155e095>] do_IRQ+0x75/0xf0
[<ffffffff815570d3>] ret_from_intr+0x0/0x11
<EOI>
[<ffffffff812fd67b>] ? acpi_idle_enter_simple+0xe4/0x119
[<ffffffff812fd674>] ? acpi_idle_enter_simple+0xdd/0x119
[<ffffffff81441c87>] cpuidle_idle_call+0xa7/0x140
[<ffffffff81008da3>] cpu_idle+0xb3/0x110
[<ffffffff81550722>] start_secondary+0x1ee/0x1f5
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 3a14630..6218890 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -516,6 +516,7 @@ void ath_deinit_leds(struct ath_softc *sc);
#define SC_OP_TSF_RESET BIT(11)
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
+#define SC_OP_ANI_RUN BIT(14)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 5af2596..41a317d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -451,6 +451,10 @@ static void ath_start_ani(struct ath_common *common)
{
struct ath_hw *ah = common->ah;
unsigned long timestamp = jiffies_to_msecs(jiffies);
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
+
+ if (!(sc->sc_flags & SC_OP_ANI_RUN))
+ return;
common->ani.longcal_timer = timestamp;
common->ani.shortcal_timer = timestamp;
@@ -766,11 +770,13 @@ static void ath9k_bss_assoc_info(struct ath_softc *sc,
/* Reset rssi stats */
sc->sc_ah->stats.avgbrssi = ATH_RSSI_DUMMY_MARKER;
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
} else {
ath_print(common, ATH_DBG_CONFIG, "Bss Info DISASSOC\n");
common->curaid = 0;
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
}
}
@@ -1376,8 +1382,10 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
if (vif->type == NL80211_IFTYPE_AP ||
vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MONITOR)
+ vif->type == NL80211_IFTYPE_MONITOR) {
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
+ }
out:
mutex_unlock(&sc->mutex);
@@ -1398,6 +1406,7 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&sc->mutex);
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
/* Reclaim beacon resources */
--
1.7.0.4
^ permalink raw reply related
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
From: John W. Linville @ 2010-06-23 14:16 UTC (permalink / raw)
To: Justin Mattock; +Cc: linux-wireless, Linux Kernel Mailing List
In-Reply-To: <AANLkTilf41JrFwN1veRDifNA78S2LQ6SO0g3YLOONd2W@mail.gmail.com>
On Tue, Jun 22, 2010 at 04:16:53PM -0700, Justin Mattock wrote:
> I remember ipsec was able to work cleanly on my machines probably
> about 4/6 months ago
> now I get this:
<snip>
Perhaps netdev would be a more appropriate list than linux-wireless
for this?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-23 14:39 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTimsEkff4sMiMB_VyWqkZOjy9PIuJ4AiC95PASOZ@mail.gmail.com>
On Tue, Jun 22, 2010 at 12:38:03PM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 12:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> > On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
> >>
> >> Does CONFIG_PCIEASPM provide a way for the user to modifiy
> >> the settings at runtime?
> >
> > You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
> >
> > http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
> > http://wireless.kernel.org/en/users/Documentation/ASPM
> >
> >> I have a Samsung N130 netbook which has a BIOS setting
> >> called "CPU Power Saving Mode". When enabled it activates
> >> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
> >> and the PCIE bridge (with the BIOS setting off it's just L1).
> >> The result is that the ethernet througput is reduced to 25Mbit/s.
> >
> > L0s is not going to buy you much gains, getting at least L1 will
> > however. L0s is just a further enhancement. I recommend you test by
> > enabling L1 and L0s, check how longer your battery lasts and then test
> > again with just L1. Then test without both L1 and L0s.
>
> So defaults should always be sane and you should not have to play with
> this stuff, unless you're a hacker, or are testing something for
> development purposes. Tweaking ASPM settings is not something a user
> should have to worry about. Period.
OK, let me put the question another way:
If enabling ASPM comes with a performance penalty (which is not unexpected,
there is usually a tradeoff between performance and power consumption),
do you think a boot time option (pcie_aspm=) or compile time option
(CONFIG_PCIEASPM) is the right user interface?
But meanwhile I found that CONFIG_PCIEASPM has a runtime
interface, /sys/module/pcie_aspm/parameters/policy.
http://lwn.net/Articles/266585/
I have not tested it on my N130 yet.
Johannes
^ permalink raw reply
* [PATCH 2/3] libertas: unmangle capability value
From: John W. Linville @ 2010-06-23 14:37 UTC (permalink / raw)
To: linux-wireless; +Cc: dkiran, Johannes Berg, John W. Linville
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
Address fall-out from patch converting libertas to use cfg80211...
+drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in assignment (different base types)
+drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short [unsigned] [usertype] capability
+drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16 [usertype] <noident>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas/cfg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 23c1dc6..f36cc97 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -1841,7 +1841,7 @@ static int lbs_ibss_start_new(struct lbs_private *priv,
if (MRVL_FW_MAJOR_REV(priv->fwrelease) <= 8)
cmd.probedelay = cpu_to_le16(CMD_SCAN_PROBE_DELAY_TIME);
/* TODO: mix in WLAN_CAPABILITY_PRIVACY */
- capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
+ capability = WLAN_CAPABILITY_IBSS;
cmd.capability = cpu_to_le16(capability);
lbs_add_rates(cmd.rates);
--
1.7.0.1
^ permalink raw reply related
* [PATCH 3/3] libertas: mark lbs_ret_802_11d_domain_info static
From: John W. Linville @ 2010-06-23 14:37 UTC (permalink / raw)
To: linux-wireless; +Cc: dkiran, Johannes Berg, John W. Linville
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
Probably little risk of namespace polution, but good practice... :-)
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas/cmdresp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/cmdresp.c b/drivers/net/wireless/libertas/cmdresp.c
index b4bc103..a0d9482 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -103,7 +103,7 @@ static int lbs_ret_reg_access(struct lbs_private *priv,
* @param resp pointer to command response buffer
* @return 0; -1
*/
-int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
+static int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
{
struct cmd_ds_802_11d_domain_info *domaininfo =
&resp->params.domaininforesp;
--
1.7.0.1
^ permalink raw reply related
* [PATCH 1/3] libertas: fix build error due to undefined symbol
From: John W. Linville @ 2010-06-23 14:37 UTC (permalink / raw)
To: linux-wireless; +Cc: dkiran, Johannes Berg, John W. Linville
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
ERROR: "mesh_handler_def" [drivers/net/wireless/libertas/libertas.ko] undefined!
Caused by a hunk missed by "Libertas: cfg80211 support" when building
with CONFIG_WIRELESS_EXT enabled.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas/mesh.c | 3 ---
drivers/net/wireless/libertas/mesh.h | 5 -----
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/libertas/mesh.c b/drivers/net/wireless/libertas/mesh.c
index 00b36b0..bc5bc13 100644
--- a/drivers/net/wireless/libertas/mesh.c
+++ b/drivers/net/wireless/libertas/mesh.c
@@ -370,9 +370,6 @@ int lbs_add_mesh(struct lbs_private *priv)
SET_NETDEV_DEV(priv->mesh_dev, priv->dev->dev.parent);
-#ifdef WIRELESS_EXT
- mesh_dev->wireless_handlers = &mesh_handler_def;
-#endif
mesh_dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
/* Register virtual mesh interface */
ret = register_netdev(mesh_dev);
diff --git a/drivers/net/wireless/libertas/mesh.h b/drivers/net/wireless/libertas/mesh.h
index e257330..84ea248 100644
--- a/drivers/net/wireless/libertas/mesh.h
+++ b/drivers/net/wireless/libertas/mesh.h
@@ -70,11 +70,6 @@ void lbs_persist_config_init(struct net_device *net);
void lbs_persist_config_remove(struct net_device *net);
-/* WEXT handler */
-
-extern struct iw_handler_def mesh_handler_def;
-
-
/* Ethtool statistics */
struct ethtool_stats;
--
1.7.0.1
^ permalink raw reply related
* Re: 2.6.34 kernel + compat-wireless + Bluez-4.66 --- no Bluetooth devices
From: Luis R. Rodriguez @ 2010-06-23 16:30 UTC (permalink / raw)
To: Andrei Moraru; +Cc: linux-wireless
In-Reply-To: <AANLkTiljOFA7zY_wyP6p-4lCTHT_dhrEUuL2ktvvOsvc@mail.gmail.com>
On Wed, Jun 23, 2010 at 2:04 AM, Andrei Moraru
<andrei.moraru.n@gmail.com> wrote:
> Hello,
>
> I have a machine with Centos 5.4, kernel version 2.6.34, Bluez-4.66,
> compat-wireless for 2.6.34 kernel version.
>
> The system knows about USB Bluetooth adapters
>
> [root@voip ~]# lsusb
> Bus 002 Device 004: ID 1131:1001 Integrated System Solution Corp.
> KY-BT100 Bluetooth Adapter
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> However, hciconfig shows no devices:
>
> [root@voip ~]# hciconfig -a
> [root@voip ~]#
>
>
> Also, hcitool dev
>
> [root@voip ~]# hcitool dev
> Devices:
>
> the dmesg output about bluetooth shows
>
> Bluetooth: Core ver 2.15
> NET: Registered protocol family 31
> Bluetooth: HCI device and connection manager initialized
> Bluetooth: HCI socket layer initialized
> Bluetooth: L2CAP ver 2.14
> Bluetooth: L2CAP socket layer initialized
> Bluetooth: SCO (Voice Link) ver 0.6
> Bluetooth: SCO socket layer initialized
> Bluetooth: HIDP (Human Interface Emulation) ver 1.2
> Bluetooth: RFCOMM TTY layer initialized
> Bluetooth: RFCOMM socket layer initialized
> Bluetooth: RFCOMM ver 1.11
> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> Bluetooth: BNEP filters: protocol multicast
>
>
> Please suggest your opinions.
dmesg looks good, repost to linux-bluetooth and show also the version
of compat-wireless you used.
Luis
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: maximilian attems @ 2010-06-23 16:33 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu Yi, linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1276186201.1835.17488.camel@rchatre-DESK>
On Thu, 10 Jun 2010, reinette chatre wrote:
> On Wed, 2010-06-09 at 18:44 -0700, Zhu Yi wrote:
> > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
>
> Not sure if it is needed but the sourceforge pages will still have the
> firmware available for download. We are in process of cleaning those
> pages up.
while you are at it:
it be cool to have the firmware license also "cleaned up" to allow
at least distribution.
thanks
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-23 16:28 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <20100623143940.GA5424@sig21.net>
On Wed, Jun 23, 2010 at 7:39 AM, Johannes Stezenbach <js@sig21.net> wrote:
> On Tue, Jun 22, 2010 at 12:38:03PM -0700, Luis R. Rodriguez wrote:
>> On Tue, Jun 22, 2010 at 12:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> > On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
>> >>
>> >> Does CONFIG_PCIEASPM provide a way for the user to modifiy
>> >> the settings at runtime?
>> >
>> > You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
>> >
>> > http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
>> > http://wireless.kernel.org/en/users/Documentation/ASPM
>> >
>> >> I have a Samsung N130 netbook which has a BIOS setting
>> >> called "CPU Power Saving Mode". When enabled it activates
>> >> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
>> >> and the PCIE bridge (with the BIOS setting off it's just L1).
>> >> The result is that the ethernet througput is reduced to 25Mbit/s.
>> >
>> > L0s is not going to buy you much gains, getting at least L1 will
>> > however. L0s is just a further enhancement. I recommend you test by
>> > enabling L1 and L0s, check how longer your battery lasts and then test
>> > again with just L1. Then test without both L1 and L0s.
>>
>> So defaults should always be sane and you should not have to play with
>> this stuff, unless you're a hacker, or are testing something for
>> development purposes. Tweaking ASPM settings is not something a user
>> should have to worry about. Period.
>
> OK, let me put the question another way:
>
> If enabling ASPM comes with a performance penalty (which is not unexpected,
> there is usually a tradeoff between performance and power consumption),
> do you think a boot time option (pcie_aspm=) or compile time option
> (CONFIG_PCIEASPM) is the right user interface?
>
>
> But meanwhile I found that CONFIG_PCIEASPM has a runtime
> interface, /sys/module/pcie_aspm/parameters/policy.
> http://lwn.net/Articles/266585/
>
> I have not tested it on my N130 yet.
Same thing, its to be used by developers not users, damn it we should
just remove this crap.
Luis
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Björn Smedman @ 2010-06-23 16:36 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <4B8D396B.5040007@openwrt.org>
2010/3/2 Felix Fietkau <nbd@openwrt.org>:
> On 2010-03-02 4:47 PM, Björn Smedman wrote:
>> 2010/3/2 Felix Fietkau <nbd@openwrt.org>:
[snip]
>> You mean the hardware interprets the block-ack and keeps retrying the
>> un-acked frames? I thought it stopped as soon as it got a block-ack to
>> let software sort out the acked and un-acked frames and handle the
>> "partial" A-MPDU retry.
> Not sure, actually. I just looked at the ath9k tx path again, and it
> seems that you're right. However it looks like it's not sending rate
> control updates until it's done with the software retry, so that's
> probably the reason why I wasn't able to make it more precise yet.
I had another look at the code now and if I read it correctly this
delay in the rate control feedback is really scary. In the extreme
case where all the rates in the MRR stop working you have to make 10
(ATH_MAX_SW_RETRIES) aggregate software retries (of about 20 frames
each) with approx 10 hardware retries each before you give the rate
control algorithm any feedback whatsoever. That is a worst case of
several thousand (pointless) subframe retransmissions before the rate
control algorithm has a chance to adjust...
If I'm not wrong above then the rate control feedback must also be
incorrect: a disaster of that magnitude simply cannot be conveyed to
the rate control algorithm through the thin tx status interface. As
far as I can tell, whenever the first subframe of an aggregate fails
and is software retried, the rate control feedback for that aggregate
is lost (ath_tx_rc_status() is never called with update_rc = true in
xmit.c).
Any ideas on how to fix this? To me the aggregation and rate control
code seems to need a major overhaul, something which would require
changes to the interface between mac80211 and drivers, e.g. ath9k.
That's out of my league unfortunately...
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: reinette chatre @ 2010-06-23 16:42 UTC (permalink / raw)
To: maximilian attems
Cc: Zhu, Yi, linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <20100623163335.GA14856@stro.at>
On Wed, 2010-06-23 at 09:33 -0700, maximilian attems wrote:
> On Thu, 10 Jun 2010, reinette chatre wrote:
>
> > On Wed, 2010-06-09 at 18:44 -0700, Zhu Yi wrote:
> > > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> >
> > Not sure if it is needed but the sourceforge pages will still have the
> > firmware available for download. We are in process of cleaning those
> > pages up.
>
> while you are at it:
> it be cool to have the firmware license also "cleaned up" to allow
> at least distribution.
Please see http://ipw2100.sourceforge.net/firmware_faq.php
Reinette
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: maximilian attems @ 2010-06-23 16:39 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu, Yi, linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1277311325.25793.2299.camel@rchatre-DESK>
On Wed, Jun 23, 2010 at 09:42:05AM -0700, reinette chatre wrote:
> On Wed, 2010-06-23 at 09:33 -0700, maximilian attems wrote:
> > On Thu, 10 Jun 2010, reinette chatre wrote:
> >
> > > On Wed, 2010-06-09 at 18:44 -0700, Zhu Yi wrote:
> > > > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> > >
> > > Not sure if it is needed but the sourceforge pages will still have the
> > > firmware available for download. We are in process of cleaning those
> > > pages up.
> >
> > while you are at it:
> > it be cool to have the firmware license also "cleaned up" to allow
> > at least distribution.
>
> Please see http://ipw2100.sourceforge.net/firmware_faq.php
I know that strange page and we (Debian) adhere to it.
still sad that you don't care to change it now that you don't care
anymore about the driver.
^ 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