Chun-Yeow Yeoh | 24 Apr 10:14 2014
Picon

[PATCH] ath10k: don't allow stand alone monitor mode for non-AP firmware

Firmware 999.999.0.636 does not allow stand alone monitor
mode. This means that bridging the STA mode and put it into
promiscuous mode will also cause the firmware to crash. Avoid
this.

Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@...>
---
 drivers/net/wireless/ath/ath10k/mac.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e2c01dc..f640328 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
 <at>  <at>  -647,10 +647,15  <at>  <at>  static int ath10k_monitor_vdev_delete(struct ath10k *ar)

 static int ath10k_monitor_start(struct ath10k *ar)
 {
-	int ret;
+	int ret = -1;

 	lockdep_assert_held(&ar->conf_mutex);

+	if (ar->fw_version_build == 636) {
+		ath10k_warn("stand alone monitor mode is not supported\n");
+		return ret;
+	}
+
 	if (!ath10k_monitor_is_enabled(ar)) {
 		ath10k_warn("trying to start monitor with no references\n");
(Continue reading)

Bjørn Mork | 24 Apr 09:49 2014
Picon

iwlmvm: High latencies and low RX rate with firmware version 22.24.8.0 but not with 22.1.7.0

Hello Emmanuel,

I hope it's OK that I send you this directly. It's mostly for
information in case the problem isn't yet known. I haven't debugged the
issue properly.  Please let me know if you want more details.

I have been using my

  iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144

module successfully with the 22.24.8.0 firware and the v3.14 driver ever
since v3.14 was out (and before, if you count the latest -rc's). This
has worked perfectly with all access points I've used, including a
802.11ac Linksys EA6700.

But yesterday I got another 802.11ac access point, a Linksys WRT1900AC,
and that gave me major problems. The problem is the same on both 2.4 and
5 GHz, so it doesn't look like it's really AC related: A few seconds
after associating, the RX rate drops to minimum (1 or 6 MBit/s
respectively), and the latency increases to high values.  After a while
frames are also being dropped, and the link becomes completely unusable.

Googling a bit brought me this: https://bbs.archlinux.org/viewtopic.php?id=180558
and I thought that I might as well try reverting to the older firmware.
And to my surprise: That made the problem go away.

I realize that icmp echos don't necessarily tell the whole truth, but
the same latency difference is noticable on e.g interactive ssh sessions
as well.  So I believe pinging illustrates the difference pretty well.
The *only* thing changed between these sessions is the iwl
(Continue reading)

Julian Sikorski | 24 Apr 08:10 2014
Picon

Low 5 GHz performance of Intel Advanced-N 6230

Dear all,

I have been moderately recently hit by a performance drop of Intel
Advanced-N 6230 card. I unfortunately do not have the "before" numbers,
but I have noticed this since I was able to stream bluray rips over nfs
to a wired Raspberry Pi a while ago and now I cannot. This has lead me
to begin investigating the issue.
In the end I have used iperf3, testing speeds between RPi and laptop,
with laptop running both Windows and Linux. iperf3 on RPi was always the
same, on the laptop it was self-compiled iperf3 git master (on Windows I
used Cygwin). Please see the observed speeds below:
- Windows: upload to RPi 93 Mbit/s, download from RPi 54 Mbit/s
- Fedora: upload to RPi 26 Mbit/s, download from RPi 48 Mbit/s

This is all on Fedora 20 x86_64. Please find attached the journalctl log
for the last boot. Please let me know if more information is needed - I
would love to get my network speeds back up to the level where I can
watch bluray rips again. Thank you for your support in advance.

Best regards,
Julian
Attachment (journalctl.log.xz): application/x-xz, 43 KiB
Bing Zhao | 23 Apr 23:40 2014

[PATCH] mwifiex: fix adapter pointer dereference

drivers/net/wireless/mwifiex/pcie.c:2252 mwifiex_pcie_fw_dump_work()
error: we previously assumed 'adapter' could be null (see line 2251)

Reported-by: Dan Carpenter <dan.carpenter@...>
Signed-off-by: Bing Zhao <bzhao@...>
---
 drivers/net/wireless/mwifiex/pcie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
index 51989b3..249fdbd 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
 <at>  <at>  -2248,7 +2248,7  <at>  <at>  static void mwifiex_pcie_fw_dump_work(struct work_struct *work)
 	};

 	if (!adapter) {
-		dev_err(adapter->dev, "Could not dump firmwware info\n");
+		pr_err("adapter is null. Could not dump firmware info\n");
 		return;
 	}

--

-- 
1.8.2.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Dan Carpenter | 23 Apr 16:30 2014
Picon

re: mwifiex: add firmware dump feature for PCIe

Hello Amitkumar Karwar,

The patch e050c76fcf49: "mwifiex: add firmware dump feature for PCIe"
from Apr 17, 2014, leads to the following static checker warning:

	drivers/net/wireless/mwifiex/pcie.c:2252 mwifiex_pcie_fw_dump_work()
	error: we previously assumed 'adapter' could be null (see line 2251)

drivers/net/wireless/mwifiex/pcie.c
  2228  /* This function dump firmware memory to file */
  2229  static void mwifiex_pcie_fw_dump_work(struct work_struct *work)
  2230  {
  2231          struct mwifiex_adapter *adapter =
  2232                          container_of(work, struct mwifiex_adapter, iface_work);
  2233          unsigned int reg, reg_start, reg_end;
  2234          u8 *dbg_ptr;
  2235          struct timeval t;
  2236          u8 dump_num = 0, idx, i, read_reg, doneflag = 0;
  2237          enum rdwr_status stat;
  2238          u32 memory_size;
  2239          u8 filename[MAX_FULL_NAME_LEN];
  2240          mm_segment_t fs;
  2241          loff_t pos;
  2242          u8 *end_ptr;
  2243          u8 *name_prefix = "/var/log/fw_dump_";
  2244          struct memory_type_mapping mem_type_mapping_tbl[] = {
  2245                  {"ITCM", NULL, NULL, 0xF0},
  2246                  {"DTCM", NULL, NULL, 0xF1},
  2247                  {"SQRAM", NULL, NULL, 0xF2},
  2248                  {"IRAM", NULL, NULL, 0xF3},
(Continue reading)

Rajkumar Manoharan | 23 Apr 11:37 2014

[PATCH] ath9k: fix race in setting ATH_OP_INVALID

The commit "ath9k: move sc_flags to ath_common" moved setting
ATH_OP_INVALID flag below ieee80211_register_hw. This is causing
the flag never being cleared randomly as the drv_start is called
prior to setting flag. Fix this by setting the flag prior to
register_hw.

Signed-off-by: Rajkumar Manoharan <rmanohar@...>
---
 drivers/net/wireless/ath/ath9k/ahb.c  | 4 ----
 drivers/net/wireless/ath/ath9k/init.c | 3 +++
 drivers/net/wireless/ath/ath9k/pci.c  | 5 -----
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index a0398fe..be3eb2a 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
 <at>  <at>  -86,7 +86,6  <at>  <at>  static int ath_ahb_probe(struct platform_device *pdev)
 	int irq;
 	int ret = 0;
 	struct ath_hw *ah;
-	struct ath_common *common;
 	char hw_name[64];

 	if (!dev_get_platdata(&pdev->dev)) {
 <at>  <at>  -146,9 +145,6  <at>  <at>  static int ath_ahb_probe(struct platform_device *pdev)
 	wiphy_info(hw->wiphy, "%s mem=0x%lx, irq=%d\n",
 		   hw_name, (unsigned long)mem, irq);

-	common = ath9k_hw_common(sc->sc_ah);
(Continue reading)

Ilan Peer | 23 Apr 08:22 2014
Picon

[PATCH] cfg80211: Fix GO Concurrent relaxation on UNII-3

At some locations, channels 149-165 are considered a single
bundle, while at some other locations, e.g., Indonesia, channels
149-161 are considered a single bundle, while channel 165 belongs
to a different bundle. This means that:

1. A station interface connection to an AP on channel 165 allows
   the instantiation of a P2P GO on channels 149-165.
2. A station interface connection to an AP on channels 149-161
   does NOT allow the instantiation of a P2P GO on channel 165.

Fix this.

Signed-off-by: Ilan Peer <ilan.peer@...>
---

Applied on top of mac80211-next/master.

 net/wireless/chan.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index c61bcdd..fb8f6a3 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
 <at>  <at>  -750,8 +750,24  <at>  <at>  static bool cfg80211_go_permissive_chan(struct cfg80211_registered_device *rdev,
 		r1 = cfg80211_get_unii(chan->center_freq);
 		r2 = cfg80211_get_unii(other_chan->center_freq);

-		if (r1 != -EINVAL && r1 == r2)
+		if (r1 != -EINVAL && r1 == r2) {
(Continue reading)

Luis R. Rodriguez | 23 Apr 01:26 2014

[PATCH] cfg80211: fix few minor issues in reg_process_hint()

From: Ilan Peer <ilan.peer@...>

commit 772f0389338cfcf96da1c178046dc7e1649ab554 upstream.

Fix the following issues in reg_process_hint():

1. Add verification that wiphy is valid before processing
   NL80211_REGDOMAIN_SET_BY_COUNTRY_IE1649ab554 of invalid initiator.
3. Remove WARN_ON check on reg_request->alpha2 as it is not a
   pointer.

[ mcgrof: Michael Leun reported a null pointer dereference against v3.14.1,
  turns out that there's a fix for this already but it wasn't propagated
  to stable. The upstream fix has been tested by Michael and has been
  confirmed to fix his issue. Below is his reported oops trace and
  original thread that reported the issue.

Micheal's report:

http://marc.info/?l=linux-wireless&m=139787057519525&w=2

Michael's oops trace:

[  116.006227] PM: Syncing filesystems ... done.
[  116.238271] PM: Preparing system for mem sleep
[  116.382917] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  116.384816] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  116.386178] PM: Entering mem sleep
[  116.386855] wlan0: deauthenticating from 90:f6:52:4e:ba:b6 by local choice (reason=3)
[  116.406743] sd 0:0:0:0: [sda] Synchronizing SCSI cache
(Continue reading)

Jean Delvare | 22 Apr 17:29 2014
Picon

[PATCH] NFC: microread: Delete dead code in microread_i2c_irq_thread_fn

Fix the following warning (with W=1):

drivers/nfc/microread/i2c.c: In function "microread_i2c_irq_thread_fn":
drivers/nfc/microread/i2c.c:215:21: warning: variable "client" set but not used [-Wunused-but-set-variable]
  struct i2c_client *client;
                     ^

Signed-off-by: Jean Delvare <jdelvare@...>
Cc: Lauro Ramos Venancio <lauro.venancio@...>
Cc: Aloisio Almeida Jr <aloisio.almeida@...>
Cc: Samuel Ortiz <sameo@...>
---
 drivers/nfc/microread/i2c.c |    3 ---
 1 file changed, 3 deletions(-)

--- linux-3.15-rc2.orig/drivers/nfc/microread/i2c.c	2014-04-22 17:14:06.962088154 +0200
+++ linux-3.15-rc2/drivers/nfc/microread/i2c.c	2014-04-22 17:25:54.467845993 +0200
 <at>  <at>  -212,7 +212,6  <at>  <at>  flush:
 static irqreturn_t microread_i2c_irq_thread_fn(int irq, void *phy_id)
 {
 	struct microread_i2c_phy *phy = phy_id;
-	struct i2c_client *client;
 	struct sk_buff *skb = NULL;
 	int r;

 <at>  <at>  -221,8 +220,6  <at>  <at>  static irqreturn_t microread_i2c_irq_thr
 		return IRQ_NONE;
 	}

-	client = phy->i2c_dev;
(Continue reading)

Jean Delvare | 22 Apr 17:25 2014
Picon

[PATCH] NFC: microread: Platform data header file clean-ups

Several clean-ups related to include/linux/platform_data/microread.h:
* Fix device name in comment.
* Don't include <linux/i2c.h> as it isn't needed.
* Include this header file from drivers/nfc/microread/i2c.c as that
  file uses struct microread_nfc_platform_data.
* Add this header file to the NFC entry in MAINTAINERS.

Signed-off-by: Jean Delvare <jdelvare@...>
Cc: Lauro Ramos Venancio <lauro.venancio@...>
Cc: Aloisio Almeida Jr <aloisio.almeida@...>
Cc: Samuel Ortiz <sameo@...>
---
That being said, the header file in question only declares struct
microread_nfc_platform_data, which is only used in
drivers/nfc/microread/i2c.c, and that piece of code doesn't access a
single field of the structure. So I am wondering if this struct and
header file are needed at all in the first place?

 MAINTAINERS                             |    1 +
 drivers/nfc/microread/i2c.c             |    1 +
 include/linux/platform_data/microread.h |    4 +---
 3 files changed, 3 insertions(+), 3 deletions(-)

--- linux-3.15-rc2.orig/include/linux/platform_data/microread.h	2014-03-31
05:40:15.000000000 +0200
+++ linux-3.15-rc2/include/linux/platform_data/microread.h	2014-04-22 17:12:06.702561202 +0200
 <at>  <at>  -1,5 +1,5  <at>  <at> 
 /*
- * Driver include for the PN544 NFC chip.
+ * Driver include for the Inside Secure microread NFC chip.
(Continue reading)

Rafał Miłecki | 22 Apr 13:54 2014
Picon

[PATCH 1/3] b43: bcma: respect GMODE (band choice) during core reset

Signed-off-by: Rafał Miłecki <zajec5@...>
---
 drivers/net/wireless/b43/main.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 07024c6..f0de7dd 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
 <at>  <at>  -1195,8 +1195,13  <at>  <at>  static void b43_bcma_wireless_core_reset(struct b43_wldev *dev, bool gmode)
 		  B43_BCMA_CLKCTLST_PHY_PLL_REQ;
 	u32 status = B43_BCMA_CLKCTLST_80211_PLL_ST |
 		     B43_BCMA_CLKCTLST_PHY_PLL_ST;
+	u32 flags;
+
+	flags = B43_BCMA_IOCTL_PHY_CLKEN;
+	if (gmode)
+		flags |= B43_BCMA_IOCTL_GMODE;
+	b43_device_enable(dev, flags);

-	b43_device_enable(dev, B43_BCMA_IOCTL_PHY_CLKEN);
 	bcma_core_set_clockmode(dev->dev->bdev, BCMA_CLKMODE_FAST);
 	b43_bcma_phy_reset(dev);
 	bcma_core_pll_ctl(dev->dev->bdev, req, status, true);
--

-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
(Continue reading)


Gmane