* [PATCH v2 1/4] rt2x00: rt2800lib: fix VGC adjustment for RT5592
From: Gabor Juhos @ 2013-10-03 18:00 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos, stable
In commit 3d81535ea5940446510a8a5cee1c6ad23c90c753
(rt2800: 5592: add chip specific vgc calculations)
the rt2800_link_tuner function has been modified to
adjust VGC level for the RT5592 chipset.
On the RT5592 chipset, the VGC level must be adjusted
only if rssi is greater than -65. However the current
code adjusts the VGC value by 0x10 regardless of the
actual chipset if the rssi value is between -80 and
-65.
Fix the broken behaviour by reordering the if-else
statements.
Cc: stable@vger.kernel.org
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index f414978..2690081 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -4469,10 +4469,13 @@ void rt2800_link_tuner(struct rt2x00_dev *rt2x00dev, struct link_qual *qual,
vgc = rt2800_get_default_vgc(rt2x00dev);
- if (rt2x00_rt(rt2x00dev, RT5592) && qual->rssi > -65)
- vgc += 0x20;
- else if (qual->rssi > -80)
- vgc += 0x10;
+ if (rt2x00_rt(rt2x00dev, RT5592)) {
+ if (qual->rssi > -65)
+ vgc += 0x20;
+ } else {
+ if (qual->rssi > -80)
+ vgc += 0x10;
+ }
rt2800_set_vgc(rt2x00dev, qual, vgc);
}
--
1.7.10
^ permalink raw reply related
* [PATCH v2 3/4] rt2x00: rt2800lib: fix default VGC values for RT3593
From: Gabor Juhos @ 2013-10-03 18:00 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1380823243-11149-1-git-send-email-juhosg@openwrt.org>
Update the rt2800_get_default_vgc function to use the same VGC
values that the DPO_RT5572_LinuxSTA_2.6.1.3_20121022 reference
driver uses.
References:
RT35xx_ChipAGCAdjust in chips/rt35xx.c
RT3593_R66_MID_LOW_SENS_GET macro in include/chip/rt3593.h
RT3593_R66_NON_MID_LOW_SEMS_GET macro in include/chips/rt3593.h
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index a619f2c..55b421f 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -4413,6 +4413,7 @@ static u8 rt2800_get_default_vgc(struct rt2x00_dev *rt2x00dev)
rt2x00_rt(rt2x00dev, RT3290) ||
rt2x00_rt(rt2x00dev, RT3390) ||
rt2x00_rt(rt2x00dev, RT3572) ||
+ rt2x00_rt(rt2x00dev, RT3593) ||
rt2x00_rt(rt2x00dev, RT5390) ||
rt2x00_rt(rt2x00dev, RT5392) ||
rt2x00_rt(rt2x00dev, RT5592))
@@ -4422,6 +4423,8 @@ static u8 rt2800_get_default_vgc(struct rt2x00_dev *rt2x00dev)
} else { /* 5GHZ band */
if (rt2x00_rt(rt2x00dev, RT3572))
vgc = 0x22 + (rt2x00dev->lna_gain * 5) / 3;
+ else if (rt2x00_rt(rt2x00dev, RT3593))
+ vgc = 0x20 + (rt2x00dev->lna_gain * 5) / 3;
else if (rt2x00_rt(rt2x00dev, RT5592))
vgc = 0x24 + (2 * rt2x00dev->lna_gain);
else {
--
1.7.10
^ permalink raw reply related
* [PATCH v2 2/4] rt2x00: rt2800lib: fix VGC adjustment for RT3572 and RT3593
From: Gabor Juhos @ 2013-10-03 18:00 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1380823243-11149-1-git-send-email-juhosg@openwrt.org>
The Ralink DPO_RT5572_LinuxSTA_2.6.1.3_20121022
reference driver uses different RSSI threshold
and VGC adjustment values for the RT3572 and
RT3593 chipsets.
Update the rt2800_link_tuner function to use the
same values. Also change the comment in the function
to make it more generic.
References:
RT35xx_ChipAGCAdjust function in chips/rt35xx.c
RSSI_FOR_MID_LOW_SENSIBILITY constant in include/chip/rtmp_phy.h
RT3593_R66_MID_LOW_SENS_GET macro in include/chip/rt3593.h
RT3593_R66_NON_MID_LOW_SEMS_GET macro in include/chips/rt3593.h
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 2690081..a619f2c 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -4462,19 +4462,34 @@ void rt2800_link_tuner(struct rt2x00_dev *rt2x00dev, struct link_qual *qual,
if (rt2x00_rt_rev(rt2x00dev, RT2860, REV_RT2860C))
return;
- /*
- * When RSSI is better then -80 increase VGC level with 0x10, except
- * for rt5592 chip.
+
+ /* When RSSI is better than a certain threshold, increase VGC
+ * with a chip specific value in order to improve the balance
+ * between sensibility and noise isolation.
*/
vgc = rt2800_get_default_vgc(rt2x00dev);
- if (rt2x00_rt(rt2x00dev, RT5592)) {
+ switch (rt2x00dev->chip.rt) {
+ case RT3572:
+ case RT3593:
+ if (qual->rssi > -65) {
+ if (rt2x00dev->curr_band == IEEE80211_BAND_2GHZ)
+ vgc += 0x20;
+ else
+ vgc += 0x10;
+ }
+ break;
+
+ case RT5592:
if (qual->rssi > -65)
vgc += 0x20;
- } else {
+ break;
+
+ default:
if (qual->rssi > -80)
vgc += 0x10;
+ break;
}
rt2800_set_vgc(rt2x00dev, qual, vgc);
--
1.7.10
^ permalink raw reply related
* [PATCH v2 4/4] rt2x00: rt2800lib: fix VGC programming for RT3572 and RT3593
From: Gabor Juhos @ 2013-10-03 18:00 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1380823243-11149-1-git-send-email-juhosg@openwrt.org>
According to the DPO_RT5572_LinuxSTA_2.6.1.3_20121022
reference driver, programming of the 'BBP 66' register
on the RT3572 and RT3593 chipsets must be done via the
'rt2800_bbp_write_with_rx_chain' function. This ensures
that value is correclty set for all RX chains.
References:
RT35xx_ChipAGCAdjust and RT35xx_SetAGCInitValue functions
in chips/rt35xx.c
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 55b421f..f81e943 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -4442,11 +4442,17 @@ static inline void rt2800_set_vgc(struct rt2x00_dev *rt2x00dev,
struct link_qual *qual, u8 vgc_level)
{
if (qual->vgc_level != vgc_level) {
- if (rt2x00_rt(rt2x00dev, RT5592)) {
+ if (rt2x00_rt(rt2x00dev, RT3572) ||
+ rt2x00_rt(rt2x00dev, RT3593)) {
+ rt2800_bbp_write_with_rx_chain(rt2x00dev, 66,
+ vgc_level);
+ } else if (rt2x00_rt(rt2x00dev, RT5592)) {
rt2800_bbp_write(rt2x00dev, 83, qual->rssi > -65 ? 0x4a : 0x7a);
rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, vgc_level);
- } else
+ } else {
rt2800_bbp_write(rt2x00dev, 66, vgc_level);
+ }
+
qual->vgc_level = vgc_level;
qual->vgc_level_reg = vgc_level;
}
--
1.7.10
^ permalink raw reply related
* RE: [PATCH v6 0/4] Bluetooth: btmrvl cal data downloading
From: Bing Zhao @ 2013-10-03 18:20 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <1EB87650-8518-47BE-B0D7-4F78E09F8691@holtmann.org>
Hi Marcel,
> I have decided to apply all 4 patches to bluetooth-next. However please send a follow up patch that
> changes the code to operate on 16-bit opcodes and not the OGC/OCF and its packing.
I will send the follow-up patch shortly.
Thanks,
Bing
^ permalink raw reply
* [PATCH] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Bing Zhao @ 2013-10-03 18:23 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-wireless,
Amitkumar Karwar, Bing Zhao
Replace ogf/ocf and its packing with 16-bit opcodes.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/bluetooth/btmrvl_drv.h | 19 +++++++++++--------
drivers/bluetooth/btmrvl_main.c | 21 +++++++++------------
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index f9d1833..e3b49c6 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -90,12 +90,12 @@ struct btmrvl_private {
#define MRVL_VENDOR_PKT 0xFE
-/* Bluetooth commands */
-#define BT_CMD_AUTO_SLEEP_MODE 0x23
-#define BT_CMD_HOST_SLEEP_CONFIG 0x59
-#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
-#define BT_CMD_MODULE_CFG_REQ 0x5B
-#define BT_CMD_LOAD_CONFIG_DATA 0x61
+/* Vendor specific Bluetooth commands */
+#define BT_CMD_AUTO_SLEEP_MODE 0xFC23
+#define BT_CMD_HOST_SLEEP_CONFIG 0xFC59
+#define BT_CMD_HOST_SLEEP_ENABLE 0xFC5A
+#define BT_CMD_MODULE_CFG_REQ 0xFC5B
+#define BT_CMD_LOAD_CONFIG_DATA 0xFC61
/* Sub-commands: Module Bringup/Shutdown Request/Response */
#define MODULE_BRINGUP_REQ 0xF1
@@ -104,6 +104,11 @@ struct btmrvl_private {
#define MODULE_SHUTDOWN_REQ 0xF2
+/* Vendor specific Bluetooth events */
+#define BT_EVENT_AUTO_SLEEP_MODE 0x23
+#define BT_EVENT_HOST_SLEEP_CONFIG 0x59
+#define BT_EVENT_HOST_SLEEP_ENABLE 0x5A
+#define BT_EVENT_MODULE_CFG_REQ 0x5B
#define BT_EVENT_POWER_STATE 0x20
/* Bluetooth Power States */
@@ -111,8 +116,6 @@ struct btmrvl_private {
#define BT_PS_DISABLE 0x03
#define BT_PS_SLEEP 0x01
-#define OGF 0x3F
-
/* Host Sleep states */
#define HS_ACTIVATED 0x01
#define HS_DEACTIVATED 0x00
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 6e7bd4e..b3dcb13 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -50,12 +50,10 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
if (hdr->evt == HCI_EV_CMD_COMPLETE) {
struct hci_ev_cmd_complete *ec;
- u16 opcode, ocf, ogf;
+ u16 opcode;
ec = (void *) (skb->data + HCI_EVENT_HDR_SIZE);
opcode = __le16_to_cpu(ec->opcode);
- ocf = hci_opcode_ocf(opcode);
- ogf = hci_opcode_ogf(opcode);
if (priv->btmrvl_dev.sendcmdflag) {
priv->btmrvl_dev.sendcmdflag = false;
@@ -63,9 +61,8 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
wake_up_interruptible(&priv->adapter->cmd_wait_q);
}
- if (ogf == OGF) {
- BT_DBG("vendor event skipped: ogf 0x%4.4x ocf 0x%4.4x",
- ogf, ocf);
+ if ((opcode & 0xfc00) == 0xfc00) {
+ BT_DBG("vendor event skipped: opcode=%#4.4x", opcode);
kfree_skb(skb);
return false;
}
@@ -89,7 +86,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
}
switch (event->data[0]) {
- case BT_CMD_AUTO_SLEEP_MODE:
+ case BT_EVENT_AUTO_SLEEP_MODE:
if (!event->data[2]) {
if (event->data[1] == BT_PS_ENABLE)
adapter->psmode = 1;
@@ -102,7 +99,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
}
break;
- case BT_CMD_HOST_SLEEP_CONFIG:
+ case BT_EVENT_HOST_SLEEP_CONFIG:
if (!event->data[3])
BT_DBG("gpio=%x, gap=%x", event->data[1],
event->data[2]);
@@ -110,7 +107,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
BT_DBG("HSCFG command failed");
break;
- case BT_CMD_HOST_SLEEP_ENABLE:
+ case BT_EVENT_HOST_SLEEP_ENABLE:
if (!event->data[1]) {
adapter->hs_state = HS_ACTIVATED;
if (adapter->psmode)
@@ -121,7 +118,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
}
break;
- case BT_CMD_MODULE_CFG_REQ:
+ case BT_EVENT_MODULE_CFG_REQ:
if (priv->btmrvl_dev.sendcmdflag &&
event->data[1] == MODULE_BRINGUP_REQ) {
BT_DBG("EVENT:%s",
@@ -166,7 +163,7 @@ exit:
}
EXPORT_SYMBOL_GPL(btmrvl_process_event);
-static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 cmd_no,
+static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 opcode,
const void *param, u8 len)
{
struct sk_buff *skb;
@@ -179,7 +176,7 @@ static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 cmd_no,
}
hdr = (struct hci_command_hdr *)skb_put(skb, HCI_COMMAND_HDR_SIZE);
- hdr->opcode = cpu_to_le16(hci_opcode_pack(OGF, cmd_no));
+ hdr->opcode = cpu_to_le16(opcode);
hdr->plen = len;
if (len)
--
1.8.0
^ permalink raw reply related
* Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Ben Greear @ 2013-10-03 18:27 UTC (permalink / raw)
To: netdev, linux-wireless@vger.kernel.org
I'm seeing something a bit strange and wondering if anyone had an opinion on why...
I am testing up to 200 wifi station systems, each with a TCP connection running
on them (download only, from VAP to stations).
Without encryption (ie, open network), I see total throughput go from
about 108Mbps down to 69Mbps as I add more stations (I add 25 at a time,
so the 108Mbps is with 25 active, and 69Mbps is with 200 active).
However, if I enable encryption, the throughput is actually higher
(111Mbps to 71Mbps). I'm doing encryption in software, so it adds a fair
bit of CPU load in this test. The numbers bounce around since this is
wifi after all, but in general encryption tends to win reliably in this
test.
When testing with a single station (and 5 tcp streams with jacked up snd/rcv buffers)
the open networks perform significantly better at total throughput: 263Mbps vs 246Mbps.
Maybe the extra delay for decryption increases odds that GRO will take
affect for the many, slower streams (and maybe that will decrease ACK traffic?)
Any other ideas?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Rick Jones @ 2013-10-03 18:50 UTC (permalink / raw)
To: Ben Greear, netdev, linux-wireless@vger.kernel.org
In-Reply-To: <524DB6F6.6020405@candelatech.com>
On 10/03/2013 11:27 AM, Ben Greear wrote:
> I'm seeing something a bit strange and wondering if anyone had an
> opinion on why...
>
> I am testing up to 200 wifi station systems, each with a TCP connection
> running on them (download only, from VAP to stations).
>
> Without encryption (ie, open network), I see total throughput go from
> about 108Mbps down to 69Mbps as I add more stations (I add 25 at a time,
> so the 108Mbps is with 25 active, and 69Mbps is with 200 active).
>
> However, if I enable encryption, the throughput is actually higher
> (111Mbps to 71Mbps). I'm doing encryption in software, so it adds a fair
> bit of CPU load in this test. The numbers bounce around since this is
> wifi after all, but in general encryption tends to win reliably in this
> test.
>
> When testing with a single station (and 5 tcp streams with jacked up
> snd/rcv buffers) the open networks perform significantly better at total throughput:
> 263Mbps vs 246Mbps.
>
> Maybe the extra delay for decryption increases odds that GRO will take
> affect for the many, slower streams (and maybe that will decrease ACK
> traffic?)
>
> Any other ideas?
Fewer times two or more stations step on one another? The recievers
will only try to transmit when they receive data. Modulo timing, if the
individual downloads are a bit slower, less chance of the receivers
looking to send ACKs back through at the same time? Got any low-level
stats for the health and well being of the wireless network?
rick jones
^ permalink raw reply
* Re: Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Ben Greear @ 2013-10-03 19:17 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, linux-wireless@vger.kernel.org
In-Reply-To: <524DBC93.1070400@hp.com>
On 10/03/2013 11:50 AM, Rick Jones wrote:
> On 10/03/2013 11:27 AM, Ben Greear wrote:
>> I'm seeing something a bit strange and wondering if anyone had an
>> opinion on why...
>>
>> I am testing up to 200 wifi station systems, each with a TCP connection
>> running on them (download only, from VAP to stations).
>>
>> Without encryption (ie, open network), I see total throughput go from
>> about 108Mbps down to 69Mbps as I add more stations (I add 25 at a time,
>> so the 108Mbps is with 25 active, and 69Mbps is with 200 active).
>>
>> However, if I enable encryption, the throughput is actually higher
>> (111Mbps to 71Mbps). I'm doing encryption in software, so it adds a fair
>> bit of CPU load in this test. The numbers bounce around since this is
>> wifi after all, but in general encryption tends to win reliably in this
>> test.
>>
>> When testing with a single station (and 5 tcp streams with jacked up
>> snd/rcv buffers) the open networks perform significantly better at total throughput:
>> 263Mbps vs 246Mbps.
>>
>> Maybe the extra delay for decryption increases odds that GRO will take
>> affect for the many, slower streams (and maybe that will decrease ACK
>> traffic?)
>>
>> Any other ideas?
>
> Fewer times two or more stations step on one another? The recievers will only try to transmit when they receive data. Modulo timing, if the individual
> downloads are a bit slower, less chance of the receivers looking to send ACKs back through at the same time? Got any low-level stats for the health and well
> being of the wireless network?
The tcp connection stats are taken after running for 60 seconds, and I take 3-sec running averages
as well as 60 second averages. So, I think that it would have to be total decrease in ACKs,
not just timing, to make a difference. The 3 and 60 second stats show consistently higher throughput
with encryption when using 25+ stations/connections.
Also, it works out that the sending sockets all sort of send randomly as they
are able, so I don't think there would be any particular ACK flood seen..
I have great quantities of low level stats, but I have not dug into them in detail
just yet. In general, my RF environment in this test is fairly controlled, as
I am cabling the systems using good semi-rigid SMA cables and an RF attenuator.
There will be some external interference of course, as they are not in an
isolation chamber.
As for the difference in 1 stations vs 25+, then it is very likely related to
low level things like MPDU working better with a single station, and probably
better ACK avoidance (I recall about 20kpps download, 4kpps upload in a previous
test with a single station, which indicates to me we must not be acking every
packet-on-the-air..somehow).
(For grins, I played with the delayed-ack-segs from an out-of-tree patch and
can get TCP throughput up to 300Mbps by setting delayed ack segs to 64 in
single station/5 stream, open network test).
Thanks,
Ben
>
> rick jones
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* pull request: wireless 2013-10-03
From: John W. Linville @ 2013-10-03 20:10 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 9847 bytes --]
Dave,
Here is another batch of fixes intended for the 3.12 stream...
For the mac80211 bits, Johannes says:
"This time I have two fixes for IBSS (including one for wext, hah), a fix
for extended rates IEs, an active monitor checking fix and a sysfs
registration race fix."
On top of those...
Amitkumar Karwar brings an mwifiex fix for an interrupt loss issue
w/ SDIO devices. The problem was due to a command timeout issue
introduced by an earlier patch.
Felix Fietkau a stall in the ath9k driver. This patch fixes the
regression introduced in the commit "ath9k: use software queues for
un-aggregated data packets".
Stanislaw Gruszka reverts an rt2x00 patch that was found to cause
connection problems with some devices.
Please let me know if there are problems!
John
---
The following changes since commit 569943d0639c85a451ea853087cbd5f738247dd9:
Merge branch 'mv643xx' (2013-10-02 17:11:50 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 1eea72f03a139146f341e450cf56934b2e01a4d3:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-10-03 16:00:03 -0400)
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: fix SDIO interrupt lost issue
Bruno Randolf (1):
cfg80211: fix warning when using WEXT for IBSS
Chun-Yeow Yeoh (1):
mac80211: fix the setting of extended supported rate IE
Felix Fietkau (2):
mac80211: drop spoofed packets in ad-hoc mode
ath9k: fix powersave response handling for BA session packets
Johannes Berg (1):
cfg80211: fix sysfs registration race
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Luciano Coelho (1):
cfg80211: use the correct macro to check for active monitor support
Stanislaw Gruszka (1):
Revert "rt2x00pci: Use PCI MSIs whenever possible"
drivers/net/wireless/ath/ath9k/xmit.c | 9 ++++++---
drivers/net/wireless/mwifiex/main.c | 6 ++++--
drivers/net/wireless/rt2x00/rt2x00pci.c | 9 +--------
net/mac80211/rx.c | 3 +++
net/mac80211/util.c | 5 +----
net/wireless/core.c | 21 +++++++++++++--------
net/wireless/ibss.c | 3 +++
net/wireless/nl80211.c | 4 ++--
8 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 5ac713d..dd30452 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1969,15 +1969,18 @@ static void ath_tx_txqaddbuf(struct ath_softc *sc, struct ath_txq *txq,
static void ath_tx_send_normal(struct ath_softc *sc, struct ath_txq *txq,
struct ath_atx_tid *tid, struct sk_buff *skb)
{
+ struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ath_frame_info *fi = get_frame_info(skb);
struct list_head bf_head;
- struct ath_buf *bf;
-
- bf = fi->bf;
+ struct ath_buf *bf = fi->bf;
INIT_LIST_HEAD(&bf_head);
list_add_tail(&bf->list, &bf_head);
bf->bf_state.bf_type = 0;
+ if (tid && (tx_info->flags & IEEE80211_TX_CTL_AMPDU)) {
+ bf->bf_state.bf_type = BUF_AMPDU;
+ ath_tx_addto_baw(sc, tid, bf);
+ }
bf->bf_next = NULL;
bf->bf_lastbf = bf;
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index fd77833..c2b91f5 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -358,10 +358,12 @@ process_start:
}
} while (true);
- if ((adapter->int_status) || IS_CARD_RX_RCVD(adapter))
+ spin_lock_irqsave(&adapter->main_proc_lock, flags);
+ if ((adapter->int_status) || IS_CARD_RX_RCVD(adapter)) {
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
goto process_start;
+ }
- spin_lock_irqsave(&adapter->main_proc_lock, flags);
adapter->mwifiex_processing = false;
spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 76d95de..dc49e52 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -105,13 +105,11 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct rt2x00_ops *ops)
goto exit_release_regions;
}
- pci_enable_msi(pci_dev);
-
hw = ieee80211_alloc_hw(sizeof(struct rt2x00_dev), ops->hw);
if (!hw) {
rt2x00_probe_err("Failed to allocate hardware\n");
retval = -ENOMEM;
- goto exit_disable_msi;
+ goto exit_release_regions;
}
pci_set_drvdata(pci_dev, hw);
@@ -152,9 +150,6 @@ exit_free_reg:
exit_free_device:
ieee80211_free_hw(hw);
-exit_disable_msi:
- pci_disable_msi(pci_dev);
-
exit_release_regions:
pci_release_regions(pci_dev);
@@ -179,8 +174,6 @@ void rt2x00pci_remove(struct pci_dev *pci_dev)
rt2x00pci_free_reg(rt2x00dev);
ieee80211_free_hw(hw);
- pci_disable_msi(pci_dev);
-
/*
* Free the PCI device data.
*/
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 54395d7..674eac1 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3056,6 +3056,9 @@ static int prepare_for_handlers(struct ieee80211_rx_data *rx,
case NL80211_IFTYPE_ADHOC:
if (!bssid)
return 0;
+ if (ether_addr_equal(sdata->vif.addr, hdr->addr2) ||
+ ether_addr_equal(sdata->u.ibss.bssid, hdr->addr2))
+ return 0;
if (ieee80211_is_beacon(hdr->frame_control)) {
return 1;
} else if (!ieee80211_bssid_match(bssid, sdata->u.ibss.bssid)) {
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index e1b34a1..9c3200b 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2103,7 +2103,7 @@ int ieee80211_add_ext_srates_ie(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_supported_band *sband;
- int rate, skip, shift;
+ int rate, shift;
u8 i, exrates, *pos;
u32 basic_rates = sdata->vif.bss_conf.basic_rates;
u32 rate_flags;
@@ -2131,14 +2131,11 @@ int ieee80211_add_ext_srates_ie(struct ieee80211_sub_if_data *sdata,
pos = skb_put(skb, exrates + 2);
*pos++ = WLAN_EID_EXT_SUPP_RATES;
*pos++ = exrates;
- skip = 0;
for (i = 8; i < sband->n_bitrates; i++) {
u8 basic = 0;
if ((rate_flags & sband->bitrates[i].flags)
!= rate_flags)
continue;
- if (skip++ < 8)
- continue;
if (need_basic && basic_rates & BIT(i))
basic = 0x80;
rate = DIV_ROUND_UP(sband->bitrates[i].bitrate,
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6715396..fe8d4f2 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -566,18 +566,13 @@ int wiphy_register(struct wiphy *wiphy)
/* check and set up bitrates */
ieee80211_set_bitrate_flags(wiphy);
-
+ rtnl_lock();
res = device_add(&rdev->wiphy.dev);
- if (res)
- return res;
-
- res = rfkill_register(rdev->rfkill);
if (res) {
- device_del(&rdev->wiphy.dev);
+ rtnl_unlock();
return res;
}
- rtnl_lock();
/* set up regulatory info */
wiphy_regulatory_register(wiphy);
@@ -606,6 +601,15 @@ int wiphy_register(struct wiphy *wiphy)
rdev->wiphy.registered = true;
rtnl_unlock();
+
+ res = rfkill_register(rdev->rfkill);
+ if (res) {
+ rfkill_destroy(rdev->rfkill);
+ rdev->rfkill = NULL;
+ wiphy_unregister(&rdev->wiphy);
+ return res;
+ }
+
return 0;
}
EXPORT_SYMBOL(wiphy_register);
@@ -640,7 +644,8 @@ void wiphy_unregister(struct wiphy *wiphy)
rtnl_unlock();
__count == 0; }));
- rfkill_unregister(rdev->rfkill);
+ if (rdev->rfkill)
+ rfkill_unregister(rdev->rfkill);
rtnl_lock();
rdev->wiphy.registered = false;
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 39bff7d..403fe29 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -263,6 +263,8 @@ int cfg80211_ibss_wext_join(struct cfg80211_registered_device *rdev,
if (chan->flags & IEEE80211_CHAN_DISABLED)
continue;
wdev->wext.ibss.chandef.chan = chan;
+ wdev->wext.ibss.chandef.center_freq1 =
+ chan->center_freq;
break;
}
@@ -347,6 +349,7 @@ int cfg80211_ibss_wext_siwfreq(struct net_device *dev,
if (chan) {
wdev->wext.ibss.chandef.chan = chan;
wdev->wext.ibss.chandef.width = NL80211_CHAN_WIDTH_20_NOHT;
+ wdev->wext.ibss.chandef.center_freq1 = freq;
wdev->wext.ibss.channel_fixed = true;
} else {
/* cfg80211_ibss_wext_join will pick one if needed */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index af8d84a..626dc3b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2421,7 +2421,7 @@ static int nl80211_set_interface(struct sk_buff *skb, struct genl_info *info)
change = true;
}
- if (flags && (*flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ if (flags && (*flags & MONITOR_FLAG_ACTIVE) &&
!(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
return -EOPNOTSUPP;
@@ -2483,7 +2483,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
info->attrs[NL80211_ATTR_MNTR_FLAGS] : NULL,
&flags);
- if (!err && (flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ if (!err && (flags & MONITOR_FLAG_ACTIVE) &&
!(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
return -EOPNOTSUPP;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: pull request: bluetooth-next 2013-10-03
From: John W. Linville @ 2013-10-03 20:19 UTC (permalink / raw)
To: Gustavo Padovan, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20131003174524.GA22728@joana>
On Thu, Oct 03, 2013 at 02:45:24PM -0300, Gustavo Padovan wrote:
> Hi John,
>
> A series of patches for 3.12. The big work here is from Marcel and Johan. They
> did a lot of work in the L2CAP, HCI and MGMT layers. The most important ones
> are the addition of a new MGMT command to enable/disable LE advertisement and
> the introduction of the HCI user channel to allow applications to get directly
> and exclusive access to Bluetooth devices.
>
> Please pull, or let me know of any issues. Thanks!
>
> Gustavo
>
> --
> The following changes since commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20:
>
> rt2800: change initialization sequence to fix system freeze (2013-09-09 14:44:34 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next for-upstream
>
> for you to fetch changes up to 4f3e219d95a3c31b916dcd5e2631c4e440736f79:
>
> Bluetooth: Only one command per L2CAP LE signalling is supported (2013-10-03 16:09:59 +0300)
Pulling now...
--
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: pull request: TI wireless drivers 2013-09-30 (for 3.13)
From: John W. Linville @ 2013-10-03 20:16 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Eliad Peller
In-Reply-To: <1380567110.4185.4.camel@porter.coelho.fi>
On Mon, Sep 30, 2013 at 09:51:50PM +0300, Luca Coelho wrote:
> Hi John,
>
> Here are some patches intended for 3.13. Eliad is upstreaming a bunch
> of patches that have been pending in the internal tree. Mostly bugfixes
> and other small improvements.
>
> Please let me know if you have any problems with it!
>
> The following changes since commit 772eb433357704ec3d6e0daa727d9ec3e85f50c1:
>
> rt2x00: Fix rf register for RT3070 (2013-09-26 15:17:30 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git for-linville
>
> for you to fetch changes up to f2cede49ae7b9f51a6fe97ada16c27e4d03d05a3:
>
> wlcore: always register dummy hardirq (2013-09-30 21:12:22 +0300)
Pulling now...
--
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: Pull request: ath 20131001
From: John W. Linville @ 2013-10-03 20:17 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath6kl-devel, ath10k
In-Reply-To: <87wqlw6fwr.fsf@kamboji.qca.qualcomm.com>
On Tue, Oct 01, 2013 at 08:48:36PM +0300, Kalle Valo wrote:
> Hi John,
>
> here's a bigger pull request including patches applied during the merge
> window. Major changes are:
>
> * throughput improvements including aligning the RX frames correctly and
> optimising HTT layer (Michal)
>
> * remove qca98xx hw1.0 support (Bartosz)
>
> * add support for firmware version 999.999.0.636 (Michal)
>
> * firmware htt statistics support (Kalle)
>
> * fix WEP in AP and IBSS mode (Marek)
>
> * fix a mutex unlock balance in debugfs file (Shafi)
>
> And of course there's a lot of smaller fixes and cleanup.
>
> To avoid the pull request getting too big, I didn't include the latest
> patches from ath.git. I'm planning to send them once you have pulled
> this one. Please let me know if there are any problems.
>
> Kalle
>
>
> The following changes since commit 9d0e2f0772d394060bf3b17cd1f3a35574365103:
>
> ath6kl: Fix invalid pointer access on fuzz testing with AP mode (2013-08-07 10:58:59 +0300)
>
> are available in the git repository at:
>
> git://github.com/kvalo/ath.git tags/for-linville-20131001
>
> for you to fetch changes up to 6e712d427cb0542afdd5220edb6e4f4f8a5b952d:
>
> ath10k: replenish HTT RX buffers in a tasklet (2013-09-26 17:22:54 +0300)
Pulling now...
--
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: [PATCH 0/7] brcmfmac: cleanup and new device support
From: John W. Linville @ 2013-10-03 20:21 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <524D543B.7010906@broadcom.com>
On Thu, Oct 03, 2013 at 01:25:47PM +0200, Arend van Spriel wrote:
> On 09/25/2013 01:05 PM, Arend van Spriel wrote:
> >This series has a few cleanup patches fixing a sparse error, cleaning
> >up the rx path and also changing the firmware filename approach after
> >getting feedback on this by Stephen Warren. The remaining patches are
> >adding support for the BCM4339 SDIO chipset.
> >
> >This series is intended for v3.13 kernel and applies to the master
> >branch of the wireless-next repository.
>
> Hi John,
>
> Did you miss this series from last week?
>
> Regards,
> Arend
No, just haven't merged everything yet... :-(
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: [PATCH] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Anderson Lizardo @ 2013-10-03 20:34 UTC (permalink / raw)
To: Bing Zhao
Cc: BlueZ development, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, linux-wireless, Amitkumar Karwar
In-Reply-To: <1380824600-13655-1-git-send-email-bzhao@marvell.com>
Hi Bing,
On Thu, Oct 3, 2013 at 2:23 PM, Bing Zhao <bzhao@marvell.com> wrote:
> @@ -63,9 +61,8 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
> wake_up_interruptible(&priv->adapter->cmd_wait_q);
> }
>
> - if (ogf == OGF) {
> - BT_DBG("vendor event skipped: ogf 0x%4.4x ocf 0x%4.4x",
> - ogf, ocf);
> + if ((opcode & 0xfc00) == 0xfc00) {
> + BT_DBG("vendor event skipped: opcode=%#4.4x", opcode);
I think you could use "if (hci_opcode_ogf(opcode) == 0x3F)" to make it
more readable.
> @@ -166,7 +163,7 @@ exit:
> }
> EXPORT_SYMBOL_GPL(btmrvl_process_event);
>
> -static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 cmd_no,
> +static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 opcode,
> const void *param, u8 len)
> {
> struct sk_buff *skb;
> @@ -179,7 +176,7 @@ static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 cmd_no,
> }
>
> hdr = (struct hci_command_hdr *)skb_put(skb, HCI_COMMAND_HDR_SIZE);
> - hdr->opcode = cpu_to_le16(hci_opcode_pack(OGF, cmd_no));
> + hdr->opcode = cpu_to_le16(opcode);
Are you sure the callers of btmrvl_send_sync_cmd() do not need to be
changed to pass an opcode instead of just the OCF?
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: pull request: wireless 2013-10-03
From: David Miller @ 2013-10-03 20:54 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20131003201023.GC3142@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 3 Oct 2013 16:10:24 -0400
> Here is another batch of fixes intended for the 3.12 stream...
>
> For the mac80211 bits, Johannes says:
>
> "This time I have two fixes for IBSS (including one for wext, hah), a fix
> for extended rates IEs, an active monitor checking fix and a sysfs
> registration race fix."
>
> On top of those...
>
> Amitkumar Karwar brings an mwifiex fix for an interrupt loss issue
> w/ SDIO devices. The problem was due to a command timeout issue
> introduced by an earlier patch.
>
> Felix Fietkau a stall in the ath9k driver. This patch fixes the
> regression introduced in the commit "ath9k: use software queues for
> un-aggregated data packets".
>
> Stanislaw Gruszka reverts an rt2x00 patch that was found to cause
> connection problems with some devices.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
From: John W. Linville @ 2013-10-03 20:57 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: linux-wireless, wcn36xx
In-Reply-To: <CAFSJ42bybEGtkzJ99fZHrcPs=gTnvJVHxM7d8anJvn1VOs7V7A@mail.gmail.com>
On Thu, Sep 26, 2013 at 11:25:18PM +0100, Eugene Krasnikov wrote:
> Hi John,
>
> This is the latest version of wcn36xx driver on top of current
> wireless-next tree. Please let me know if you have any problems with
> applying it.
>
> 2013/9/26 Eugene Krasnikov <k.eugene.e@gmail.com>:
> > This is a mac80211 driver for Qualcomm WCN3660/WCN3680 devices. So
> > far WCN3660/WCN3680 is available only on MSM platform.
> >
> > Firmware can be found here:
> > https://www.codeaurora.org/cgit/external/hisense/platform/vendor/qcom-opensource/wlan/prima/tree/firmware_bin?h=8130_CS
> >
> > Wiki page is available here:
> > http://wireless.kernel.org/en/users/Drivers/wcn36xx
> >
> > A lot people made a contribution to this driver. Here is the list in
> > alphabetical order:
> >
> > Eugene Krasnikov <k.eugene.e@gmail.com>
> > Kalle Valo <kvalo@qca.qualcomm.com>
> > Olof Johansson <dev@skyshaper.net>
> > Pontus Fuchs <pontus.fuchs@gmail.com>
> > Yanbo Li <yanbol@qti.qualcomm.com>
> >
> > Signed-off-by: Eugene Krasnikov <k.eugene.e@gmail.com>
'make allyesconfig' yield this:
LD drivers/net/wireless/ath/ath.o
LD drivers/net/wireless/ath/built-in.o
drivers/net/wireless/ath/wcn36xx/built-in.o: In function `_GLOBAL__sub_I_65535_0_wcn36xx_set_default_rates':
/home/linville/git/wireless-next/drivers/net/wireless/ath/wcn36xx/main.c:302: multiple definition of `debug_mask'
drivers/net/wireless/ath/ath6kl/built-in.o:/home/linville/git/wireless-next/drivers/net/wireless/ath/ath6kl/cfg80211.c:1208: first defined here
make[2]: *** [drivers/net/wireless/ath/built-in.o] Error 1
make[1]: *** [drivers/net/wireless/ath] Error 2
make: *** [drivers/net/wireless/] Error 2
--
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: [PATCH] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Bing Zhao @ 2013-10-03 21:06 UTC (permalink / raw)
To: Anderson Lizardo
Cc: BlueZ development, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <CAJdJm_N1=a7URKmU8xOsOzOaYHKQdNXiR7VryeOc4+i2uf7RqQ@mail.gmail.com>
Hi Anderson,
Thanks for your comments.
> > - if (ogf == OGF) {
> > - BT_DBG("vendor event skipped: ogf 0x%4.4x ocf 0x%4.4x",
> > - ogf, ocf);
> > + if ((opcode & 0xfc00) == 0xfc00) {
> > + BT_DBG("vendor event skipped: opcode=%#4.4x", opcode);
>
> I think you could use "if (hci_opcode_ogf(opcode) == 0x3F)" to make it
> more readable.
Sure, I will make that change in v2.
> > @@ -179,7 +176,7 @@ static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 cmd_no,
> > }
> >
> > hdr = (struct hci_command_hdr *)skb_put(skb, HCI_COMMAND_HDR_SIZE);
> > - hdr->opcode = cpu_to_le16(hci_opcode_pack(OGF, cmd_no));
> > + hdr->opcode = cpu_to_le16(opcode);
>
> Are you sure the callers of btmrvl_send_sync_cmd() do not need to be
> changed to pass an opcode instead of just the OCF?
Previously we pass the cmd_no which is the OCF bits to the function, and the function packs it to opcode.
Now I changed the macros of the cmd_no from OCF to opcode as shown below, so no change to the callers.
-/* Bluetooth commands */
-#define BT_CMD_AUTO_SLEEP_MODE 0x23
-#define BT_CMD_HOST_SLEEP_CONFIG 0x59
-#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
-#define BT_CMD_MODULE_CFG_REQ 0x5B
-#define BT_CMD_LOAD_CONFIG_DATA 0x61
+/* Vendor specific Bluetooth commands */
+#define BT_CMD_AUTO_SLEEP_MODE 0xFC23
+#define BT_CMD_HOST_SLEEP_CONFIG 0xFC59
+#define BT_CMD_HOST_SLEEP_ENABLE 0xFC5A
+#define BT_CMD_MODULE_CFG_REQ 0xFC5B
+#define BT_CMD_LOAD_CONFIG_DATA 0xFC61
Thanks,
Bing
^ permalink raw reply
* [PATCH v2] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Bing Zhao @ 2013-10-03 21:19 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Anderson Lizardo,
linux-wireless, Amitkumar Karwar, Bing Zhao
Replace ogf/ocf and its packing with 16-bit opcodes.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Use hci_opcode_ogf() to make code more readable. (Anderson Lizardo)
drivers/bluetooth/btmrvl_drv.h | 19 +++++++++++--------
drivers/bluetooth/btmrvl_main.c | 21 +++++++++------------
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index f9d1833..e3b49c6 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -90,12 +90,12 @@ struct btmrvl_private {
#define MRVL_VENDOR_PKT 0xFE
-/* Bluetooth commands */
-#define BT_CMD_AUTO_SLEEP_MODE 0x23
-#define BT_CMD_HOST_SLEEP_CONFIG 0x59
-#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
-#define BT_CMD_MODULE_CFG_REQ 0x5B
-#define BT_CMD_LOAD_CONFIG_DATA 0x61
+/* Vendor specific Bluetooth commands */
+#define BT_CMD_AUTO_SLEEP_MODE 0xFC23
+#define BT_CMD_HOST_SLEEP_CONFIG 0xFC59
+#define BT_CMD_HOST_SLEEP_ENABLE 0xFC5A
+#define BT_CMD_MODULE_CFG_REQ 0xFC5B
+#define BT_CMD_LOAD_CONFIG_DATA 0xFC61
/* Sub-commands: Module Bringup/Shutdown Request/Response */
#define MODULE_BRINGUP_REQ 0xF1
@@ -104,6 +104,11 @@ struct btmrvl_private {
#define MODULE_SHUTDOWN_REQ 0xF2
+/* Vendor specific Bluetooth events */
+#define BT_EVENT_AUTO_SLEEP_MODE 0x23
+#define BT_EVENT_HOST_SLEEP_CONFIG 0x59
+#define BT_EVENT_HOST_SLEEP_ENABLE 0x5A
+#define BT_EVENT_MODULE_CFG_REQ 0x5B
#define BT_EVENT_POWER_STATE 0x20
/* Bluetooth Power States */
@@ -111,8 +116,6 @@ struct btmrvl_private {
#define BT_PS_DISABLE 0x03
#define BT_PS_SLEEP 0x01
-#define OGF 0x3F
-
/* Host Sleep states */
#define HS_ACTIVATED 0x01
#define HS_DEACTIVATED 0x00
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 6e7bd4e..ffec74e 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -50,12 +50,10 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
if (hdr->evt == HCI_EV_CMD_COMPLETE) {
struct hci_ev_cmd_complete *ec;
- u16 opcode, ocf, ogf;
+ u16 opcode;
ec = (void *) (skb->data + HCI_EVENT_HDR_SIZE);
opcode = __le16_to_cpu(ec->opcode);
- ocf = hci_opcode_ocf(opcode);
- ogf = hci_opcode_ogf(opcode);
if (priv->btmrvl_dev.sendcmdflag) {
priv->btmrvl_dev.sendcmdflag = false;
@@ -63,9 +61,8 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
wake_up_interruptible(&priv->adapter->cmd_wait_q);
}
- if (ogf == OGF) {
- BT_DBG("vendor event skipped: ogf 0x%4.4x ocf 0x%4.4x",
- ogf, ocf);
+ if (hci_opcode_ogf(opcode) == 0x3F) {
+ BT_DBG("vendor event skipped: opcode=%#4.4x", opcode);
kfree_skb(skb);
return false;
}
@@ -89,7 +86,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
}
switch (event->data[0]) {
- case BT_CMD_AUTO_SLEEP_MODE:
+ case BT_EVENT_AUTO_SLEEP_MODE:
if (!event->data[2]) {
if (event->data[1] == BT_PS_ENABLE)
adapter->psmode = 1;
@@ -102,7 +99,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
}
break;
- case BT_CMD_HOST_SLEEP_CONFIG:
+ case BT_EVENT_HOST_SLEEP_CONFIG:
if (!event->data[3])
BT_DBG("gpio=%x, gap=%x", event->data[1],
event->data[2]);
@@ -110,7 +107,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
BT_DBG("HSCFG command failed");
break;
- case BT_CMD_HOST_SLEEP_ENABLE:
+ case BT_EVENT_HOST_SLEEP_ENABLE:
if (!event->data[1]) {
adapter->hs_state = HS_ACTIVATED;
if (adapter->psmode)
@@ -121,7 +118,7 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
}
break;
- case BT_CMD_MODULE_CFG_REQ:
+ case BT_EVENT_MODULE_CFG_REQ:
if (priv->btmrvl_dev.sendcmdflag &&
event->data[1] == MODULE_BRINGUP_REQ) {
BT_DBG("EVENT:%s",
@@ -166,7 +163,7 @@ exit:
}
EXPORT_SYMBOL_GPL(btmrvl_process_event);
-static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 cmd_no,
+static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 opcode,
const void *param, u8 len)
{
struct sk_buff *skb;
@@ -179,7 +176,7 @@ static int btmrvl_send_sync_cmd(struct btmrvl_private *priv, u16 cmd_no,
}
hdr = (struct hci_command_hdr *)skb_put(skb, HCI_COMMAND_HDR_SIZE);
- hdr->opcode = cpu_to_le16(hci_opcode_pack(OGF, cmd_no));
+ hdr->opcode = cpu_to_le16(opcode);
hdr->plen = len;
if (len)
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
From: Eugene Krasnikov @ 2013-10-03 21:22 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, wcn36xx
In-Reply-To: <20131003205710.GH3142@tuxdriver.com>
Hm, weird... do not see this problem myself. Let me try to sync latest
wireless-next and will try to apply latest patch from this mailthread
on top.
P.S. If somebody esle can try to apply this patch and build that would
be useful to know if problem is visible on others PCs as well.
2013/10/3 John W. Linville <linville@tuxdriver.com>:
> On Thu, Sep 26, 2013 at 11:25:18PM +0100, Eugene Krasnikov wrote:
>> Hi John,
>>
>> This is the latest version of wcn36xx driver on top of current
>> wireless-next tree. Please let me know if you have any problems with
>> applying it.
>>
>> 2013/9/26 Eugene Krasnikov <k.eugene.e@gmail.com>:
>> > This is a mac80211 driver for Qualcomm WCN3660/WCN3680 devices. So
>> > far WCN3660/WCN3680 is available only on MSM platform.
>> >
>> > Firmware can be found here:
>> > https://www.codeaurora.org/cgit/external/hisense/platform/vendor/qcom-opensource/wlan/prima/tree/firmware_bin?h=8130_CS
>> >
>> > Wiki page is available here:
>> > http://wireless.kernel.org/en/users/Drivers/wcn36xx
>> >
>> > A lot people made a contribution to this driver. Here is the list in
>> > alphabetical order:
>> >
>> > Eugene Krasnikov <k.eugene.e@gmail.com>
>> > Kalle Valo <kvalo@qca.qualcomm.com>
>> > Olof Johansson <dev@skyshaper.net>
>> > Pontus Fuchs <pontus.fuchs@gmail.com>
>> > Yanbo Li <yanbol@qti.qualcomm.com>
>> >
>> > Signed-off-by: Eugene Krasnikov <k.eugene.e@gmail.com>
>
> 'make allyesconfig' yield this:
>
> LD drivers/net/wireless/ath/ath.o
> LD drivers/net/wireless/ath/built-in.o
> drivers/net/wireless/ath/wcn36xx/built-in.o: In function `_GLOBAL__sub_I_65535_0_wcn36xx_set_default_rates':
> /home/linville/git/wireless-next/drivers/net/wireless/ath/wcn36xx/main.c:302: multiple definition of `debug_mask'
> drivers/net/wireless/ath/ath6kl/built-in.o:/home/linville/git/wireless-next/drivers/net/wireless/ath/ath6kl/cfg80211.c:1208: first defined here
> make[2]: *** [drivers/net/wireless/ath/built-in.o] Error 1
> make[1]: *** [drivers/net/wireless/ath] Error 2
> make: *** [drivers/net/wireless/] Error 2
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
--
Best regards,
Eugene
^ permalink raw reply
* Re: Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Ben Greear @ 2013-10-03 23:19 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, linux-wireless@vger.kernel.org
In-Reply-To: <524DC2B8.905@candelatech.com>
I was seeing an un-expectedly bad wifi train rates, so I changed to ath9k-rate-control,
rebooted, and re-ran the tests. Throughput is much improved. I really hope it wasn't just
a reboot that fixed it, but too burned out to do more tests today.
I still see better TCP throughput with WPA2 when using 25-200 stations/streams.
For anyone who wants to wade through some big automated reports, see the links
near the top of this page (suggestions for improving those reports are welcome):
http://www.candelatech.com/lf_wifi_examples.php
(The 600 station reports are a bit dated and were done in a fairly busy
wifi environment. We'll re-run those sometime soon-ish.)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Anderson Lizardo @ 2013-10-03 23:26 UTC (permalink / raw)
To: Bing Zhao
Cc: BlueZ development, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F451FB266@SC-VEXCH1.marvell.com>
Hi Bing,
On Thu, Oct 3, 2013 at 5:06 PM, Bing Zhao <bzhao@marvell.com> wrote:
>> > hdr = (struct hci_command_hdr *)skb_put(skb, HCI_COMMAND_HDR_SIZE);
>> > - hdr->opcode = cpu_to_le16(hci_opcode_pack(OGF, cmd_no));
>> > + hdr->opcode = cpu_to_le16(opcode);
>>
>> Are you sure the callers of btmrvl_send_sync_cmd() do not need to be
>> changed to pass an opcode instead of just the OCF?
>
> Previously we pass the cmd_no which is the OCF bits to the function, and the function packs it to opcode.
>
> Now I changed the macros of the cmd_no from OCF to opcode as shown below, so no change to the callers.
>
> -/* Bluetooth commands */
> -#define BT_CMD_AUTO_SLEEP_MODE 0x23
> -#define BT_CMD_HOST_SLEEP_CONFIG 0x59
> -#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
> -#define BT_CMD_MODULE_CFG_REQ 0x5B
> -#define BT_CMD_LOAD_CONFIG_DATA 0x61
> +/* Vendor specific Bluetooth commands */
> +#define BT_CMD_AUTO_SLEEP_MODE 0xFC23
> +#define BT_CMD_HOST_SLEEP_CONFIG 0xFC59
> +#define BT_CMD_HOST_SLEEP_ENABLE 0xFC5A
> +#define BT_CMD_MODULE_CFG_REQ 0xFC5B
> +#define BT_CMD_LOAD_CONFIG_DATA 0xFC61
Now I got it :)
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH v2] rt2x00: rt2800lib: remove duplicate rf_vals for RF3053
From: Kevin Lo @ 2013-10-04 1:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users
We already have rf_vals_3x with same values. Hence rf_vals_3053 is removed
in this patch.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
---
Changes since v1:
- update comment of rf_vals_3x to indicate that it also supports RF3053
- add Paul's Acked-by tag
---
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 25aaa5e..78ce749 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -7224,7 +7224,7 @@ static const struct rf_channel rf_vals[] = {
/*
* RF value list for rt3xxx
- * Supports: 2.4 GHz (all) & 5.2 GHz (RF3052)
+ * Supports: 2.4 GHz (all) & 5.2 GHz (RF3052 & RF3053)
*/
static const struct rf_channel rf_vals_3x[] = {
{1, 241, 2, 2 },
@@ -7420,72 +7420,6 @@ static const struct rf_channel
rf_vals_5592_xtal40[] = {
{196, 83, 0, 12, 1},
};
-static const struct rf_channel rf_vals_3053[] = {
- /* Channel, N, R, K */
- {1, 241, 2, 2},
- {2, 241, 2, 7},
- {3, 242, 2, 2},
- {4, 242, 2, 7},
- {5, 243, 2, 2},
- {6, 243, 2, 7},
- {7, 244, 2, 2},
- {8, 244, 2, 7},
- {9, 245, 2, 2},
- {10, 245, 2, 7},
- {11, 246, 2, 2},
- {12, 246, 2, 7},
- {13, 247, 2, 2},
- {14, 248, 2, 4},
-
- {36, 0x56, 0, 4},
- {38, 0x56, 0, 6},
- {40, 0x56, 0, 8},
- {44, 0x57, 0, 0},
- {46, 0x57, 0, 2},
- {48, 0x57, 0, 4},
- {52, 0x57, 0, 8},
- {54, 0x57, 0, 10},
- {56, 0x58, 0, 0},
- {60, 0x58, 0, 4},
- {62, 0x58, 0, 6},
- {64, 0x58, 0, 8},
-
- {100, 0x5B, 0, 8},
- {102, 0x5B, 0, 10},
- {104, 0x5C, 0, 0},
- {108, 0x5C, 0, 4},
- {110, 0x5C, 0, 6},
- {112, 0x5C, 0, 8},
-
- /* NOTE: Channel 114 has been removed intentionally.
- * The EEPROM contains no TX power values for that,
- * and it is disabled in the vendor driver as well.
- */
-
- {116, 0x5D, 0, 0},
- {118, 0x5D, 0, 2},
- {120, 0x5D, 0, 4},
- {124, 0x5D, 0, 8},
- {126, 0x5D, 0, 10},
- {128, 0x5E, 0, 0},
- {132, 0x5E, 0, 4},
- {134, 0x5E, 0, 6},
- {136, 0x5E, 0, 8},
- {140, 0x5F, 0, 0},
-
- {149, 0x5F, 0, 9},
- {151, 0x5F, 0, 11},
- {153, 0x60, 0, 1},
- {157, 0x60, 0, 5},
- {159, 0x60, 0, 7},
- {161, 0x60, 0, 9},
- {165, 0x61, 0, 1},
- {167, 0x61, 0, 3},
- {169, 0x61, 0, 5},
- {171, 0x61, 0, 7},
- {173, 0x61, 0, 9},
-};
-
static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
{
struct hw_mode_spec *spec = &rt2x00dev->spec;
@@ -7575,14 +7509,11 @@ static int rt2800_probe_hw_mode(struct
rt2x00_dev *rt2x00dev)
rt2x00_rf(rt2x00dev, RF5392)) {
spec->num_channels = 14;
spec->channels = rf_vals_3x;
- } else if (rt2x00_rf(rt2x00dev, RF3052)) {
+ } else if (rt2x00_rf(rt2x00dev, RF3052) ||
+ rt2x00_rf(rt2x00dev, RF3053)) {
spec->supported_bands |= SUPPORT_BAND_5GHZ;
spec->num_channels = ARRAY_SIZE(rf_vals_3x);
spec->channels = rf_vals_3x;
- } else if (rt2x00_rf(rt2x00dev, RF3053)) {
- spec->supported_bands |= SUPPORT_BAND_5GHZ;
- spec->num_channels = ARRAY_SIZE(rf_vals_3053);
- spec->channels = rf_vals_3053;
} else if (rt2x00_rf(rt2x00dev, RF5592)) {
spec->supported_bands |= SUPPORT_BAND_5GHZ;
^ permalink raw reply related
* Re: [PATCH] rt2x00: rt2800lib: remove duplicate rf_vals for RF3053.
From: Kevin Lo @ 2013-10-04 1:41 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <524D5DCE.80601@openwrt.org>
Gabor Juhos wrote:
> 2013.10.03. 9:48 keltezéssel, Kevin Lo írta:
>> We already have rf_vals_3x with same values. Hence rf_vals_3053 is removed
>> in this patch.
>>
>> Signed-off-by: Kevin Lo <kevlo@kevlo.org>
> For completeness, the comment of rf_vals_3x should be updated to indicate that
> it also supports RF3053. Otherwise the patch is fine.
Ok, I'll send an updated patch, thanks.
>
> -Gabor
>
Kevin
^ permalink raw reply
* Re: [GIT PULL] firmware: wl1251 firmware binary
From: Luca Coelho @ 2013-10-04 5:01 UTC (permalink / raw)
To: balbi; +Cc: dwmw2, ben, Linux Kernel Mailing List, linux-wireless,
Pavel Machek
In-Reply-To: <20131002125535.GL1476@radagast>
Hi Felipe,
On Wed, 2013-10-02 at 07:55 -0500, Felipe Balbi wrote:
> Hi,
>
> here's a pull request for wl4 firmware. I'll send a patch for wl1251
> driver updating firmware load path.
>
> The following changes since commit b8ac7c7e27dcd13fa3c843aaf62457e9c57ea4db:
>
> linux-firmware: Add Brocade FC/FCOE Adapter firmware files (2013-09-30 04:53:32 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware.git wilink4
>
> for you to fetch changes up to d726804dbc8dad88587b6be17716714cd91ed86c:
>
> ti-connectivity: add wl1251 firmware and license (2013-10-02 06:55:39 -0500)
>
> ----------------------------------------------------------------
> Felipe Balbi (1):
> ti-connectivity: add wl1251 firmware and license
>
> LICENCE.wl1251 | 59 +++++++++++++++++++++++++++++++++++++++++
> WHENCE | 18 +++++++++++++
> ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes
> ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes
> 4 files changed, 77 insertions(+)
> create mode 100644 LICENCE.wl1251
> create mode 100644 ti-connectivity/wl1251-fw.bin
> create mode 100644 ti-connectivity/wl1251-nvs.bin
Since you didn't send v2 of the patch, you could have used the -p option
with git request-pull so we could see the changes you made here...
--
Cheers,
Luca.
^ 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