Peter Oh | 26 Jan 23:25 2015

[PATCH] ath10k: Replace ioread with wmb for data sync

Using ioread() to perform data sync is excessive.
Use compact API, wmb(), that intended to be used for the case.
It reduces total 14 CPU clocks per interrupt.

Signed-off-by: Peter Oh <poh@...>
 drivers/net/wireless/ath/ath10k/pci.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 3b40a86..c353a2c 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
 <at>  <at>  -346,10 +346,8  <at>  <at>  static void ath10k_pci_disable_and_clear_legacy_irq(struct ath10k *ar)

-	/* IMPORTANT: this extra read transaction is required to
-	 * flush the posted write buffer. */
-	(void)ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS +
+	/* invoke data sync barrier */
+	wmb();

 static void ath10k_pci_enable_legacy_irq(struct ath10k *ar)
 <at>  <at>  -358,10 +356,8  <at>  <at>  static void ath10k_pci_enable_legacy_irq(struct ath10k *ar)

(Continue reading)

Larry Finger | 26 Jan 22:32 2015

Re: rtl8192ee issues

On 01/26/2015 02:47 PM, Burton Williams wrote:
> Hi All -
> I am having problems with getting my wireless card to work. Here is what i did.
> I downloaded backports 3.18.1 and compiled and installed the wifi package
> against my 3.17.8 kernel. (I'm running FC21). Then i modprobe -r r8192ee and
> modprobe rtl8192ee. On first attempt i was able to connect to a wifi network and
> see a link speed of more than 6mbs. (144 to be exact) So way better than i was
> seeing before. I however did not see the network that is broadcasting on 5ghz.
> Attached are copies of my dmesg from modprobe fwd.
> Please let me know if I can do something else, or if i did something
> incorrectly. Any help is appreciated.
> Hardware is t440s running FC21 kernel   3.17.8-300.fc21.x86_64

To the best of my knowledge, the RTL8192EE chip has no 5 GHz radio, thus there 
is no way you could see a 5 GHz AP. I will recheck that with Realtek and let you 
know if my information is wrong.


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

David Ramos | 26 Jan 20:52 2015

Uninitialized memcpy length (segfault) in airo_get_essid (drivers/net/wireless/airo.c)


Our UC-KLEE tool found an uninitialized memcpy length (segfault) bug in airo_get_essid
(drivers/net/wireless/airo.c). We found the bug in kernel 3.16.3, but it appears to date back beyond the
original kernel git commit in 2005 (1da177e4c3f41524e886b7f1b8a0c1fc7321cac2).

The offending code is as follows:

5912   readStatusRid(local, &status_rid, 1);
5914   /* Note : if dwrq->flags != 0, we should                                                                                                                                                    
5915    * get the relevant SSID from the SSID list... */
5917   /* Get the current SSID */
5918   memcpy(extra, status_rid.SSID, le16_to_cpu(status_rid.SSIDlen));

The call to readStatusRid() on line 5912 fails if PC4500_readrid() fails, which can happen if
down_interruptible() fails (e.g., is interrupted). This leaves the ‘status_rid’ struct
uninitialized. The memcpy() at line 5918 then uses garbage values from the stack as the memcpy length,
which can corrupt memory or cause a kernel segfault.

The recommended fix is to check the return value of readStatusRid() and return an error when it fails.

Please let me know if you have any questions.


To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
(Continue reading)

Michael Büsch | 26 Jan 18:26 2015

[PATCH] b43: Fix locking FIXME in beacon update top half

b43 has a FIXME about locking in the mac80211 set-beacon-int callback for a long time.
As it turns out there actually is a tiny race window that could result in
a use-after-free bug of the 'current_beacon' memory.
Nobody ever reported this, so it probably never happened.

Fix this by adding a spin lock that protects the current_beacon access.
We must not be in atomic context while accessing hardware (due to SDIO),
so the beacon update bottom half has to clone the skb and release the lock
before writing it to hardware.

Let's all hope that this stops the troll who is trying to submit incorrect
fixes for this issue repeatedly.
And let's hope that I'm not a troll, too, who just hides even more evil code
in an even more complex attempt to fix the issue.

Signed-off-by: Michael Buesch <m <at>>
Tested-by: Larry Finger <Larry.Finger@...>


Index: linux/drivers/net/wireless/b43/b43.h
--- linux.orig/drivers/net/wireless/b43/b43.h
+++ linux/drivers/net/wireless/b43/b43.h
 <at>  <at>  -941,6 +941,7  <at>  <at>  struct b43_wl {
 	bool beacon1_uploaded;
 	bool beacon_templates_virgin; /* Never wrote the templates? */
 	struct work_struct beacon_update_trigger;
+	spinlock_t beacon_lock;

(Continue reading)

Rajkumar Manoharan | 26 Jan 17:43 2015

[PATCH] ath10k: fix target wakeup timeout

During drv_start/drv_stop stress testing in ARM platform,
sometimes target is taking more that 5ms to wake up. Similar
behaviour also noted during driver load and unload iterations.
On such cases, the wakup duration lies between 5-6ms. Hence
increasing pci wakup timeout 10ms to be more safer. With this
changes, able to complete power down/up >100 iterations without
any issues.

Signed-off-by: Rajkumar Manoharan <rmanohar@...>
 drivers/net/wireless/ath/ath10k/pci.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index ce4a1ef..bddf543 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
 <at>  <at>  -194,7 +194,7  <at>  <at>  static inline struct ath10k_pci *ath10k_pci_priv(struct ath10k *ar)

 #define ATH_PCI_RESET_WAIT_MAX 10 /* ms */
-#define PCIE_WAKE_TIMEOUT 5000	/* 5ms */
+#define PCIE_WAKE_TIMEOUT 10000	/* 10ms */

 #define BAR_NUM 0



(Continue reading)

Robert Dolca | 26 Jan 12:13 2015

[PATCH v2 0/2] Add ACPI support for NXP PN544

This patch set introduces ACPI support for PN544.

gpio_set_value was replaced with gpio_set_value_cansleep in order
to allow GPIO access that may sleep. This is particularelly useful
when GPIO is accessed using busses like I2C, SPI, USB

Changes since v1:
	- Added cover letter
	- Removed debug define and Kconfig include
	- Minor fixes to patch subjects

Links to v1:

Robert Dolca (2):
  NFC: PN544: GPIO access that may sleep
  NFC: Add ACPI support for NXP PN544

 drivers/nfc/pn544/i2c.c | 137 +++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 124 insertions(+), 13 deletions(-)



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

(Continue reading)

Nicholas Mc Guire | 26 Jan 07:26 2015

[PATCH RFC] wlcore: match wait_for_completion_timeout return type

return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate return type and assignment.

Signed-off-by: Nicholas Mc Guire <der.herr@...>

The return type of wait_for_completion_timeout is unsigned long not
int. This patch adds a separate variable of proper type for handling
of the wait_for_completion_timeout.

The alternative would be to fold it into the if condition and not use
a separate variable like so:

	if (!pending) {
		if (!wait_for_completion_timeout( &compl,
				msecs_to_jiffies(WL1271_WAKEUP_TIMEOUT)) {
			wl1271_error("ELP wakeup timeout!");		    
			ret = -ETIMEDOUT;
			goto err;

not sure if this or the below solution is preferable.

Patch was compile tested only for x86_64_defconfig + CONFIG_WL_TI=y, 

Patch is against 3.19.0-rc5 -next-20150123

(Continue reading)

Fu, Zhonghui | 26 Jan 03:46 2015

[PATCH] brcmfmac: avoid duplicated suspend/resume operation

From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
From: Zhonghui Fu <zhonghui.fu@...>
Date: Mon, 26 Jan 2015 10:13:21 +0800
Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation

WiFi chip has 2 SDIO functions, and PM core will trigger
twice suspend/resume operations for one WiFi chip to do
the same things. This patch avoid this case.

Acked-by: Arend van Spriel<arend@...>
Signed-off-by: Zhonghui Fu <zhonghui.fu@...>
 drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 9880dae..618b545 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
 <at>  <at>  -1139,11 +1139,17  <at>  <at>  void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
 static int brcmf_ops_sdio_suspend(struct device *dev)
 	struct brcmf_bus *bus_if = dev_get_drvdata(dev);
-	struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
+	struct brcmf_sdio_dev *sdiodev;
 	mmc_pm_flag_t sdio_flags;
+	struct sdio_func *func = dev_to_sdio_func(dev);

 	brcmf_dbg(SDIO, "Enter\n");

(Continue reading)

Christopher M. Penalver | 26 Jan 03:00 2015

Inquiry on sudo iw dev wlan1 set txpower fixed 14 -> command failed: Invalid argument (-22)

Attempting to follow
I get:
sudo iw dev wlan1 set txpower fixed 14
command failed: Invalid argument (-22)

Same error if I raise or lower this number.

My environment:

+ Ubuntu 14.10 (also reproducible in 14.04)

+ (Also reproducible in 3.13.x)
uname -a
Linux acer-pc 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15 22:27:29 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

+ I am in the US regulatory domain.

+ wlan1
T:  Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=050d ProdID=845a Rev=02.00
S:  Manufacturer=Manufacturer Realtek
S:  Product=Belkin USB Wireless Adaptor
S:  SerialNumber=00e04c000001
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=ff Prot=ff Driver=r8712u

(Continue reading)

Rafał Miłecki | 25 Jan 22:02 2015

[PATCH RFC] bcma: add helper function bringing PCIe hosted bus up

Bringing PCIe hosted bus up requires operating on host-related core.
Since we plan to support PCIe Gen 2 devices we should provide a helper
picking the correct core (PCIE or PCIE2).

Signed-off-by: Rafał Miłecki <zajec5@...>
What do you think about this? Any comments?
Do you think putting such a helper in host_pci.c is OK?
I plan to provide similar changes for bcma_core_pci_down & bcma_core_pci_irq_ctl
 drivers/bcma/bcma_private.h                    |  1 +
 drivers/bcma/driver_pci.c                      | 10 +---------
 drivers/bcma/host_pci.c                        | 17 +++++++++++++++++
 drivers/net/wireless/b43/main.c                |  2 +-
 drivers/net/wireless/brcm80211/brcmsmac/main.c |  2 +-
 include/linux/bcma/bcma.h                      |  2 ++
 include/linux/bcma/bcma_driver_pci.h           |  1 -
 7 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index ac6c5fc..9123741 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
 <at>  <at>  -101,6 +101,7  <at>  <at>  static inline void __exit bcma_host_soc_unregister_driver(void)

 /* driver_pci.c */
 u32 bcma_pcie_read(struct bcma_drv_pci *pc, u32 address);
+void bcma_core_pci_up(struct bcma_drv_pci *pc);

 extern int bcma_chipco_watchdog_register(struct bcma_drv_cc *cc);
(Continue reading)

Arend van Spriel | 25 Jan 20:31 2015

[PATCH 00/14] brcm80211: sdio suspend rework and other fixes

This patch series reworks some code in SDIO part of the brcmfmac
driver related to suspend/resume that were found doing stress testing.
In PCIe part scheduling of worker thread needed to be relaxed.
Other changes involve minor fixes and exposing firmware revision
information to user-space, ie. ethtool.

This series is intended for v3.20 and applies to the master branch
of the wireless-drivers-next repository.

Arend van Spriel (9):
  brcmfmac: pass DEAUTH/DISASSOC reason code to user-space
  brcmfmac: wait for driver to go idle during suspend
  brcmfmac: do not load firmware when device is already running
  brcmutil: use define for boardrev string function
  brcmfmac: determine chip info when not provided by bus layer
  brcmfmac: always obtain device revision info upon intialization
  brcmfmac: show firmware release info in ethtool driver info
  brcmfmac: store revinfo retrieval result
  brcmfmac: fix nvram processing

Hante Meuleman (5):
  brcmfmac: Relax scheduling of msgbuf worker on high throughput.
  brcmfmac: prevent possible deadlock on resuming SDIO device.
  brcmfmac: use SDIO DPC for control frames.
  brcmfmac: SDIO: avoid using bus state for private states.
  brcmfmac: Reopen netdev queue on bus state data.

 drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c   |  70 ++++-----
 drivers/net/wireless/brcm80211/brcmfmac/bus.h      |  24 +--
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c |  31 +++-
(Continue reading)