Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: rtlwifi rtl8192cu: unable to use channels 12 and 13 in Europe
From: Xose Vazquez Perez @ 2013-07-23 10:50 UTC (permalink / raw)
  To: linux-wireless, Larry Finger
In-Reply-To: <51C637B2.8090000@gmail.com>

On 06/23/2013 01:48 AM, Xose Vazquez Perez wrote:
> hi,
> 
> kernel 3.9.7-100.fc17.x86_64
> 
> - dmesg:
> 
> usb 2-1.5: new high-speed USB device number 16 using ehci-pci
> usb 2-1.5: New USB device found, idVendor=0bda, idProduct=8176
> usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 2-1.5: Product: 802.11n WLAN Adapter
> usb 2-1.5: Manufacturer: Realtek
> usb 2-1.5: SerialNumber: 00e04c000001
> rtl8192cu: Chip version 0x10
> rtl8192cu: MAC address: 00:e0:4c:07:dd:45
> rtl8192cu: Board Type 0
> rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
> rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
> ieee80211 phy11: Selected rate control algorithm 'rtl_rc'
> rtlwifi: wireless switch is on
> cfg80211: Calling CRDA for country: ES
> cfg80211: Regulatory domain changed to country: ES
> cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> cfg80211:   (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
> cfg80211:   (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> cfg80211:   (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> cfg80211:   (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
> cfg80211:   (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
> rtl8192cu: MAC auto ON okay!
> rtl8192cu: Tx queue select: 0x05
> IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> 
> 
> - iw list:
> 
> Wiphy phy2
>         Band 1:
>                 Capabilities: 0x1862
>                         HT20/HT40
>                         Static SM Power Save
>                         RX HT20 SGI
>                         RX HT40 SGI
>                         No RX STBC
>                         Max AMSDU length: 7935 bytes
>                         DSSS/CCK HT40
>                 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
>                 Minimum RX AMPDU time spacing: 16 usec (0x07)
>                 HT TX/RX MCS rate indexes supported: 0-7, 32
>                 Frequencies:
>                         * 2412 MHz [1] (20.0 dBm)
>                         * 2417 MHz [2] (20.0 dBm)
>                         * 2422 MHz [3] (20.0 dBm)
>                         * 2427 MHz [4] (20.0 dBm)
>                         * 2432 MHz [5] (20.0 dBm)
>                         * 2437 MHz [6] (20.0 dBm)
>                         * 2442 MHz [7] (20.0 dBm)
>                         * 2447 MHz [8] (20.0 dBm)
>                         * 2452 MHz [9] (20.0 dBm)
>                         * 2457 MHz [10] (20.0 dBm)
>                         * 2462 MHz [11] (20.0 dBm)
>                         * 2467 MHz [12] (disabled)
>                         * 2472 MHz [13] (disabled)
>                         * 2484 MHz [14] (disabled)
>                 Bitrates (non-HT):
>                         * 1.0 Mbps
>                         * 2.0 Mbps
>                         * 5.5 Mbps
>                         * 11.0 Mbps
>                         * 6.0 Mbps
>                         * 9.0 Mbps
>                         * 12.0 Mbps
>                         * 18.0 Mbps
>                         * 24.0 Mbps
>                         * 36.0 Mbps
>                         * 48.0 Mbps
>                         * 54.0 Mbps
>         max # scan SSIDs: 4
>         max scan IEs length: 2257 bytes
>         RTS threshold: 2347
>         Coverage class: 0 (up to 0m)
>         Supported Ciphers:
>                 * WEP40 (00-0f-ac:1)
>                 * WEP104 (00-0f-ac:5)
>                 * TKIP (00-0f-ac:2)
>                 * CCMP (00-0f-ac:4)
>         Available Antennas: TX 0 RX 0
>         Supported interface modes:
>                  * IBSS
>                  * managed
>                  * AP
>                  * AP/VLAN
>                  * monitor
>         software interface modes (can always be added):
>                  * AP/VLAN
>                  * monitor
>         interface combinations are not supported
>         Supported commands:
>                  * new_interface
>                  * set_interface
>                  * new_key
>                  * new_beacon
>                  * new_station
>                  * new_mpath
>                  * set_mesh_params
>                  * set_bss
>                  * authenticate
>                  * associate
>                  * deauthenticate
>                  * disassociate
>                  * join_ibss
>                  * join_mesh
>                  * set_tx_bitrate_mask
>                  * action
>                  * frame_wait_cancel
>                  * set_wiphy_netns
>                  * set_channel
>                  * set_wds_peer
>                  * Unknown command (84)
>                  * Unknown command (87)
>                  * Unknown command (85)
>                  * Unknown command (89)
>                  * Unknown command (92)
>                  * connect
>                  * disconnect
>         Supported TX frame types:
>                  * IBSS: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                  * managed: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                  * AP: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                  * AP/VLAN: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                  * mesh point: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                  * P2P-client: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                  * P2P-GO: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                  * Unknown mode (10): 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>         Supported RX frame types:
>                  * IBSS: 0x0040 0x00b0 0x00c0 0x00d0
>                  * managed: 0x0040 0x00d0
>                  * AP: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
>                  * AP/VLAN: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
>                  * mesh point: 0x00b0 0x00c0 0x00d0
>                  * P2P-client: 0x0040 0x00d0
>                  * P2P-GO: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
>                  * Unknown mode (10): 0x0040 0x00d0
>         HT Capability overrides:
>                  * MCS: ff ff ff ff ff ff ff ff ff ff
>                  * maximum A-MSDU length
>                  * supported channel width
>                  * short GI for 40 MHz
>                  * max A-MPDU length exponent
>                  * min MPDU start spacing
>         Device supports TX status socket option.
>         Device supports HT-IBSS.
> 
> 
> thank you.
> 

It also happens in 3.10.2. This time CC Larry.

thanks.

^ permalink raw reply

* [PATCH] ath9k: Fix diversity combining for AR9285
From: Sujith Manoharan @ 2013-07-23 10:55 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless

From: Sujith Manoharan <c_manoha@qca.qualcomm.com>

When antenna diversity combining is enabled in the EEPROM,
the initial values for the MAIN/ALT config have to be
programmed correctly. This patch adds it for AR9285.

Since the diversity combining macros are common to all chip
families, remove the redundant AR9285 macros and move the
definitions to phy.h.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/ar9002_phy.h    |  4 ----
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.c |  4 ++--
 drivers/net/wireless/ath/ath9k/ar9003_phy.c    |  4 ++--
 drivers/net/wireless/ath/ath9k/ar9003_phy.h    |  5 -----
 drivers/net/wireless/ath/ath9k/ath9k.h         |  7 -------
 drivers/net/wireless/ath/ath9k/eeprom_4k.c     | 19 +++++++++++++++++++
 drivers/net/wireless/ath/ath9k/phy.h           |  7 +++++++
 7 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.h b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
index f9eb2c3..d3f0928 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
@@ -317,10 +317,6 @@
 #define AR_PHY_9285_ANT_DIV_ALT_GAINTB_S    29
 #define AR_PHY_9285_ANT_DIV_MAIN_GAINTB     0x40000000
 #define AR_PHY_9285_ANT_DIV_MAIN_GAINTB_S   30
-#define AR_PHY_9285_ANT_DIV_LNA1            2
-#define AR_PHY_9285_ANT_DIV_LNA2            1
-#define AR_PHY_9285_ANT_DIV_LNA1_PLUS_LNA2  3
-#define AR_PHY_9285_ANT_DIV_LNA1_MINUS_LNA2 0
 #define AR_PHY_9285_ANT_DIV_GAINTB_0        0
 #define AR_PHY_9285_ANT_DIV_GAINTB_1        1
 
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index d105e43..a98e6a3 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3673,9 +3673,9 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
 				     AR_PHY_ANT_DIV_ALT_GAINTB |
 				     AR_PHY_ANT_DIV_MAIN_GAINTB));
 			/* by default use LNA1 for the main antenna */
-			regval |= (AR_PHY_ANT_DIV_LNA1 <<
+			regval |= (ATH_ANT_DIV_COMB_LNA1 <<
 				   AR_PHY_ANT_DIV_MAIN_LNACONF_S);
-			regval |= (AR_PHY_ANT_DIV_LNA2 <<
+			regval |= (ATH_ANT_DIV_COMB_LNA2 <<
 				   AR_PHY_ANT_DIV_ALT_LNACONF_S);
 			REG_WRITE(ah, AR_PHY_MC_GAIN_CTRL, regval);
 		}
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 2db4ddf..3ec33ce 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1465,8 +1465,8 @@ static void ar9003_hw_antctrl_shared_chain_lnadiv(struct ath_hw *ah,
 			AR_PHY_ANT_DIV_ALT_LNACONF |
 			AR_PHY_ANT_DIV_MAIN_GAINTB |
 			AR_PHY_ANT_DIV_ALT_GAINTB);
-		regval |= (AR_PHY_ANT_DIV_LNA1 << AR_PHY_ANT_DIV_MAIN_LNACONF_S);
-		regval |= (AR_PHY_ANT_DIV_LNA2 << AR_PHY_ANT_DIV_ALT_LNACONF_S);
+		regval |= (ATH_ANT_DIV_COMB_LNA1 << AR_PHY_ANT_DIV_MAIN_LNACONF_S);
+		regval |= (ATH_ANT_DIV_COMB_LNA2 << AR_PHY_ANT_DIV_ALT_LNACONF_S);
 		REG_WRITE(ah, AR_PHY_MC_GAIN_CTRL, regval);
 	}
 }
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.h b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
index d4d39f3..23c019d 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
@@ -296,11 +296,6 @@
 #define AR_PHY_ANT_DIV_MAIN_GAINTB              0x40000000
 #define AR_PHY_ANT_DIV_MAIN_GAINTB_S            30
 
-#define AR_PHY_ANT_DIV_LNA1_MINUS_LNA2          0x0
-#define AR_PHY_ANT_DIV_LNA2                     0x1
-#define AR_PHY_ANT_DIV_LNA1                     0x2
-#define AR_PHY_ANT_DIV_LNA1_PLUS_LNA2           0x3
-
 #define AR_PHY_EXTCHN_PWRTHR1   (AR_AGC_BASE + 0x2c)
 #define AR_PHY_EXT_CHN_WIN      (AR_AGC_BASE + 0x30)
 #define AR_PHY_20_40_DET_THR    (AR_AGC_BASE + 0x34)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index c1224b5..76e38d3 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -591,13 +591,6 @@ static inline void ath_fill_led_pin(struct ath_softc *sc)
 #define ATH_ANT_DIV_COMB_LNA1_DELTA_MID -2
 #define ATH_ANT_DIV_COMB_LNA1_DELTA_LOW 2
 
-enum ath9k_ant_div_comb_lna_conf {
-	ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2,
-	ATH_ANT_DIV_COMB_LNA2,
-	ATH_ANT_DIV_COMB_LNA1,
-	ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2,
-};
-
 struct ath_ant_comb {
 	u16 count;
 	u16 total_pkt_count;
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index c2bfd748..9ea8e4b 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -812,6 +812,7 @@ static void ath9k_hw_4k_set_gain(struct ath_hw *ah,
 static void ath9k_hw_4k_set_board_values(struct ath_hw *ah,
 					 struct ath9k_channel *chan)
 {
+	struct ath9k_hw_capabilities *pCap = &ah->caps;
 	struct modal_eep_4k_header *pModal;
 	struct ar5416_eeprom_4k *eep = &ah->eeprom.map4k;
 	struct base_eep_header_4k *pBase = &eep->baseEepHeader;
@@ -858,6 +859,24 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw *ah,
 
 		REG_WRITE(ah, AR_PHY_CCK_DETECT, regVal);
 		regVal = REG_READ(ah, AR_PHY_CCK_DETECT);
+
+		if (pCap->hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
+			/*
+			 * If diversity combining is enabled,
+			 * set MAIN to LNA1 and ALT to LNA2 initially.
+			 */
+			regVal = REG_READ(ah, AR_PHY_MULTICHAIN_GAIN_CTL);
+			regVal &= (~(AR_PHY_9285_ANT_DIV_MAIN_LNACONF |
+				     AR_PHY_9285_ANT_DIV_ALT_LNACONF));
+
+			regVal |= (ATH_ANT_DIV_COMB_LNA1 <<
+				   AR_PHY_9285_ANT_DIV_MAIN_LNACONF_S);
+			regVal |= (ATH_ANT_DIV_COMB_LNA2 <<
+				   AR_PHY_9285_ANT_DIV_ALT_LNACONF_S);
+			regVal &= (~(AR_PHY_9285_FAST_DIV_BIAS));
+			regVal |= (0 << AR_PHY_9285_FAST_DIV_BIAS_S);
+			REG_WRITE(ah, AR_PHY_MULTICHAIN_GAIN_CTL, regVal);
+		}
 	}
 
 	if (pModal->version >= 2) {
diff --git a/drivers/net/wireless/ath/ath9k/phy.h b/drivers/net/wireless/ath/ath9k/phy.h
index 8b38030..4a1b992 100644
--- a/drivers/net/wireless/ath/ath9k/phy.h
+++ b/drivers/net/wireless/ath/ath9k/phy.h
@@ -48,4 +48,11 @@
 #define AR_PHY_PLL_CONTROL 0x16180
 #define AR_PHY_PLL_MODE 0x16184
 
+enum ath9k_ant_div_comb_lna_conf {
+	ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2,
+	ATH_ANT_DIV_COMB_LNA2,
+	ATH_ANT_DIV_COMB_LNA1,
+	ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2,
+};
+
 #endif
-- 
1.8.3.3


^ permalink raw reply related

* Re: [PATCH] Make BCMA_HOST_SOC depend on BCM47XX
From: Florian Fainelli @ 2013-07-23 11:06 UTC (permalink / raw)
  To: Rafał Miłecki; +Cc: Hauke Mehrtens, John W. Linville, linux-wireless
In-Reply-To: <CACna6rwU6-jC_cnU=vGv2u2D11aUCKNZN-YOuM9GYt_R9E79oA@mail.gmail.com>

2013/7/23 Rafał Miłecki <zajec5@gmail.com>:
> 2013/7/23 Hauke Mehrtens <hauke@hauke-m.de>:
>> On 07/23/2013 04:31 AM, John W. Linville wrote:
>>> From: "John W. Linville" <linville@tuxdriver.com>
>>>
>>> Otherwise, 'make allyesconfig' generates this:
>>>
>>>   CC [M]  drivers/net/ethernet/broadcom/bgmac.o
>>> drivers/net/ethernet/broadcom/bgmac.c:19:27: fatal error:
>>> bcm47xx_nvram.h: No such file or directory
>>> compilation terminated.
>>> make[4]: *** [drivers/net/ethernet/broadcom/bgmac.o] Error 1
>>> make[3]: *** [drivers/net/ethernet/broadcom] Error 2
>>> make[2]: *** [drivers/net/ethernet] Error 2
>>> make[1]: *** [drivers/net] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>> ---
>>>  drivers/bcma/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
>>> index 7c081b3..a2bdab1 100644
>>> --- a/drivers/bcma/Kconfig
>>> +++ b/drivers/bcma/Kconfig
>>> @@ -36,7 +36,7 @@ config BCMA_DRIVER_PCI_HOSTMODE
>>>
>>>  config BCMA_HOST_SOC
>>>       bool "Support for BCMA in a SoC"
>>> -     depends on BCMA
>>> +     depends on BCMA && BCM47XX
>>>       help
>>>         Host interface for a Broadcom AIX bus directly mapped into
>>>         the memory. This only works with the Broadcom SoCs from the
>>>
>> I think bgmac should depend on BCM47XX.
>
> Yeah, I'm wondering about that.
>
> It's bgmac that calls BCM47XX specific functions (nvram).

And this is bad, make that a platform_data callback or something like
that such that there is no build-time dependency on nvram functions.

>
> On the other hand it doesn't make much sense to use BCMA_HOST_SOC on
> anything else than BCM47XX, does it?

Hauke has been working on BCM53XX which is an ARM-based BCM47XX-like
SoC, but that just means depends on (BCM47XX || ARCH_BCM53XX) then.
--
Florian

^ permalink raw reply

* [PATCH] mac80211: fix monitor interface suspend crash regression
From: Stanislaw Gruszka @ 2013-07-23 11:56 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, Ortwin Glück

My commit:

commit 12e7f517029dad819c45eca9ca01fdb9ba57616b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Feb 28 10:55:26 2013 +0100

    mac80211: cleanup generic suspend/resume procedures

removed check for deleting MONITOR and AP_VLAN when suspend. That can
cause a crash (i.e. in iwlagn_mac_remove_interface()) since we remove
interface in the driver that we did not add before.

Reference:
http://marc.info/?l=linux-kernel&m=137391815113860&w=2

Bisected-by: Ortwin Glück <odi@odi.ch>
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Cc: stable@vger.kernel.org # 3.10
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
 net/mac80211/pm.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 7fc5d0d..3401262 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -99,10 +99,13 @@ int __ieee80211_suspend(struct ieee80211_hw *hw, struct cfg80211_wowlan *wowlan)
 	}
 	mutex_unlock(&local->sta_mtx);
 
-	/* remove all interfaces */
+	/* remove all interfaces that were created in the driver */
 	list_for_each_entry(sdata, &local->interfaces, list) {
-		if (!ieee80211_sdata_running(sdata))
+		if (!ieee80211_sdata_running(sdata) ||
+		    sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+		    sdata->vif.type == NL80211_IFTYPE_MONITOR)
 			continue;
+
 		drv_remove_interface(local, sdata);
 	}
 
-- 
1.7.11.7


^ permalink raw reply related

* Re: [PATCH] mac80211: fix monitor interface suspend crash regression
From: Johannes Berg @ 2013-07-23 12:02 UTC (permalink / raw)
  To: Stanislaw Gruszka; +Cc: linux-wireless, Ortwin Glück
In-Reply-To: <20130723115650.GB1687@redhat.com>

On Tue, 2013-07-23 at 13:56 +0200, Stanislaw Gruszka wrote:
> My commit:
> 
> commit 12e7f517029dad819c45eca9ca01fdb9ba57616b
> Author: Stanislaw Gruszka <sgruszka@redhat.com>
> Date:   Thu Feb 28 10:55:26 2013 +0100
> 
>     mac80211: cleanup generic suspend/resume procedures
> 
> removed check for deleting MONITOR and AP_VLAN when suspend. That can
> cause a crash (i.e. in iwlagn_mac_remove_interface()) since we remove
> interface in the driver that we did not add before.

Applied, thanks.

johannes


^ permalink raw reply

* Re: rtl8192cu: slow path warning
From: Paul Rolland @ 2013-07-23 12:29 UTC (permalink / raw)
  To: Richard Genoud
  Cc: Larry Finger, Chaoming Li, John W. Linville, linux-wireless,
	linux-kernel, rol
In-Reply-To: <CACQ1gAh+WjQZHo+_afZpzcwt1=KPM8VMBOe=YCHN_LEZu+jPNQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Hello,

On Thu, 27 Jun 2013 09:33:20 +0200
Richard Genoud <richard.genoud@gmail.com> wrote:

> Yes, of course, you can add my
> Reported-by: Richard Genoud <richard.genoud@gmail.com>
> 
> But the patch doesn't compile on my platform ( since I'm on ARM, I
> haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) :
> 
> ERROR: "rtl_lps_change_work_callback"
> [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined!

Is that the reason why this patch is not yet in 3.10.x or 3.11-rcY ?
I'm running a 3.10.1 with USB dongle including 8192CU, and I can see this
warning when the machine starts.
I've check 3.10.1, 3.10.2 and 3.11-rc3 source code, but this fix is not
there. Is there a different fix that went in in 3.10.2 or 3.11-rc?

Best,
Paul

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* [PATCH] wireless: rt2x00: rt2800usb: add RT3573 devices
From: Xose Vazquez Perez @ 2013-07-23 12:55 UTC (permalink / raw)
  Cc: Xose Vazquez Perez, Ivo van Doorn, Gertjan van Wingerde,
	Helmut Schaa, John W. Linville, users, linux-wireless

taken from Ralink linux and windows drivers:

0x1b75, 0x7733 AirLive 450Mbps Wireless-N Dual Band USB Adapter
0x0b05, 0x17bc ASUS USB-N66 450Mbps Dual Band USB Adapter
0x0b05, 0x17ad ASUS USB-N66 Dual Band N Network Adapter
0x050d, 0x1103 Belkin Wireless Adapter
0x148f, 0xf301 Cameo Ralink3573 3x3 single band USB dongle
0x7392, 0x7733 Edimax
0x0e66, 0x0020 Hawking HD45U Dual Band USB Wireless-N Adapter
0x0e66, 0x0021 Hawking HD45U Dual Band Wls-450N Adapter
0x04bb, 0x094e I-O DATA WN-AG450U Wireless LAN Adapter
0x0789, 0x016b Logitec LAN-W450AN/U2
0x0846, 0x9012 NETGEAR WNDA4100 N900 Wireless Dual Band USB Adapter
0x0846, 0x9019 NETGEAR WNDA4200D Wireless Dual Band USB Adapter
0x2019, 0xed19 Planex GW-USDual450
0x148f, 0x3573 Ralink 802.11n USB Wireless LAN Card
0x0df6, 0x0067 Sitecom Wireless Dualband Network Adapter N750 X6
0x0df6, 0x006a Sitecom Wireless Dualband Network Adapter N900 X7
0x0586, 0x3421 ZyXEL Dual-Band Wireless N450 USB Adapter

Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: users@rt2x00.serialmonkey.com
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
 drivers/net/wireless/rt2x00/rt2800usb.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index ab609ae..fc9efdf 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1198,8 +1198,38 @@ static struct usb_device_id rt2800usb_device_table[] = {
 	{ USB_DEVICE(0x5a57, 0x0284) },
 #endif
 #ifdef CONFIG_RT2800USB_RT3573
+	/* AirLive */
+	{ USB_DEVICE(0x1b75, 0x7733) },
+	/* ASUS */
+	{ USB_DEVICE(0x0b05, 0x17bc) },
+	{ USB_DEVICE(0x0b05, 0x17ad) },
+	/* Belkin */
+	{ USB_DEVICE(0x050d, 0x1103) },
+	/* Cameo */
+	{ USB_DEVICE(0x148f, 0xf301) },
+	/* Edimax */
+	{ USB_DEVICE(0x7392, 0x7733) },
+	/* Hawking */
+	{ USB_DEVICE(0x0e66, 0x0020) },
+	{ USB_DEVICE(0x0e66, 0x0021) },
+	/* I-O DATA */
+	{ USB_DEVICE(0x04bb, 0x094e) },
 	/* Linksys */
 	{ USB_DEVICE(0x13b1, 0x003b) },
+	/* Logitec */
+	{ USB_DEVICE(0x0789, 0x016b) },
+	/* NETGEAR */
+	{ USB_DEVICE(0x0846, 0x9012) },
+	{ USB_DEVICE(0x0846, 0x9019) },
+	/* Planex */
+	{ USB_DEVICE(0x2019, 0xed19) },
+	/* Ralink */
+	{ USB_DEVICE(0x148f, 0x3573) },
+	/* Sitecom */
+	{ USB_DEVICE(0x0df6, 0x0067) },
+	{ USB_DEVICE(0x0df6, 0x006a) },
+	/* ZyXEL */
+	{ USB_DEVICE(0x0586, 0x3421) },
 #endif
 #ifdef CONFIG_RT2800USB_RT53XX
 	/* Arcadyan */
-- 
1.8.3.1


^ permalink raw reply related

* Re: [NETWORKING DRIVERS RT2X00] please add support for Asus PCE-N53 (0x1814, 0x5592)
From: Xose Vazquez Perez @ 2013-07-23 13:56 UTC (permalink / raw)
  To: treeve, linux-wireless, users@rt2x00.serialmonkey.com

Treeve Jelbert wrote:

> linux-3.10.0 does not support device  (0x1814, 0x5592) Asus PCE-N53 which I 
> would like to use on with 5GHz network.
> 
> #lspci
> 02:00.0 Network controller: Ralink corp. Device 5592
>         Subsystem: ASUSTeK Computer Inc. Device 851a
> 
> # lspci -d :5592 -nn
> 02:00.0 Network controller [0280]: Ralink corp. Device [1814:5592]

RT5592 devices are still unsupported by rt2x00 drivers.
Stanislaw Gruszka <stf_xl@wp.pl> was working on it.

^ permalink raw reply

* Re: rtl8192cu: slow path warning
From: Paul Rolland @ 2013-07-23 14:26 UTC (permalink / raw)
  To: Richard Genoud
  Cc: Paul Rolland, Larry Finger, Chaoming Li, John W. Linville,
	linux-wireless, linux-kernel
In-Reply-To: <20130723142907.53103aab@tux.DEF.witbe.net>


[-- Attachment #1.1: Type: text/plain, Size: 1319 bytes --]

Hello Richard,

If you still have the required HW and still would like a patch to remove
that warning on your machine, could you please try the attached one ?

I slightly reworked the original patch by moving the function
rtl_lps_change_work_callback from pci.c to ps.c. 

I've successfully compiled that on my machine, but I have PCI set in
my .config, so I'd like your feedback.

Best,
Paul

On Tue, 23 Jul 2013 14:29:07 +0200
Paul Rolland (ポール・ロラン)  <rol@witbe.net> wrote:

> Hello,
> 
> On Thu, 27 Jun 2013 09:33:20 +0200
> Richard Genoud <richard.genoud@gmail.com> wrote:
> 
> > Yes, of course, you can add my
> > Reported-by: Richard Genoud <richard.genoud@gmail.com>
> > 
> > But the patch doesn't compile on my platform ( since I'm on ARM, I
> > haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) :
> > 
> > ERROR: "rtl_lps_change_work_callback"
> > [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined!
> 
> Is that the reason why this patch is not yet in 3.10.x or 3.11-rcY ?
> I'm running a 3.10.1 with USB dongle including 8192CU, and I can see this
> warning when the machine starts.
> I've check 3.10.1, 3.10.2 and 3.11-rc3 source code, but this fix is not
> there. Is there a different fix that went in in 3.10.2 or 3.11-rc?
> 
> Best,
> Paul


[-- Attachment #1.2: patch --]
[-- Type: application/octet-stream, Size: 2461 bytes --]

diff -uprN -X /usr/src/linux-3.10.2/Documentation/dontdiff rtlwifi.orig/pci.c rtlwifi/pci.c
--- rtlwifi.orig/pci.c	2013-07-23 15:29:47.000000000 +0200
+++ rtlwifi/pci.c	2013-07-23 15:30:59.000000000 +0200
@@ -1008,19 +1008,6 @@ static void _rtl_pci_prepare_bcn_tasklet
 	return;
 }
 
-static void rtl_lps_change_work_callback(struct work_struct *work)
-{
-	struct rtl_works *rtlworks =
-	    container_of(work, struct rtl_works, lps_change_work);
-	struct ieee80211_hw *hw = rtlworks->hw;
-	struct rtl_priv *rtlpriv = rtl_priv(hw);
-
-	if (rtlpriv->enter_ps)
-		rtl_lps_enter(hw);
-	else
-		rtl_lps_leave(hw);
-}
-
 static void _rtl_pci_init_trx_var(struct ieee80211_hw *hw)
 {
 	struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
diff -uprN -X /usr/src/linux-3.10.2/Documentation/dontdiff rtlwifi.orig/ps.c rtlwifi/ps.c
--- rtlwifi.orig/ps.c	2013-07-23 15:29:47.000000000 +0200
+++ rtlwifi/ps.c	2013-07-23 15:49:50.000000000 +0200
@@ -922,3 +922,17 @@ void rtl_p2p_info(struct ieee80211_hw *h
 	else
 		rtl_p2p_noa_ie(hw, data, len - FCS_LEN);
 }
+
+void rtl_lps_change_work_callback(struct work_struct *work)
+{
+	struct rtl_works *rtlworks =
+	    container_of(work, struct rtl_works, lps_change_work);
+	struct ieee80211_hw *hw = rtlworks->hw;
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+	if (rtlpriv->enter_ps)
+		rtl_lps_enter(hw);
+	else
+		rtl_lps_leave(hw);
+}
+
diff -uprN -X /usr/src/linux-3.10.2/Documentation/dontdiff rtlwifi.orig/ps.h rtlwifi/ps.h
--- rtlwifi.orig/ps.h	2013-07-23 15:29:47.000000000 +0200
+++ rtlwifi/ps.h	2013-07-23 15:32:15.000000000 +0200
@@ -49,5 +49,6 @@ void rtl_swlps_rf_awake(struct ieee80211
 void rtl_swlps_rf_sleep(struct ieee80211_hw *hw);
 void rtl_p2p_ps_cmd(struct ieee80211_hw *hw, u8 p2p_ps_state);
 void rtl_p2p_info(struct ieee80211_hw *hw, void *data, unsigned int len);
+void rtl_lps_change_work_callback(struct work_struct *work);
 
 #endif
diff -uprN -X /usr/src/linux-3.10.2/Documentation/dontdiff rtlwifi.orig/usb.c rtlwifi/usb.c
--- rtlwifi.orig/usb.c	2013-07-23 15:29:47.000000000 +0200
+++ rtlwifi/usb.c	2013-07-23 15:32:51.000000000 +0200
@@ -1070,6 +1070,8 @@ int rtl_usb_probe(struct usb_interface *
 	spin_lock_init(&rtlpriv->locks.usb_lock);
 	INIT_WORK(&rtlpriv->works.fill_h2c_cmd,
 		  rtl_fill_h2c_cmd_work_callback);
+	INIT_WORK(&rtlpriv->works.lps_change_work,
+		  rtl_lps_change_work_callback);
 
 	rtlpriv->usb_data_index = 0;
 	init_completion(&rtlpriv->firmware_loading_complete);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: rtl8192cu: slow path warning
From: Richard Genoud @ 2013-07-23 15:00 UTC (permalink / raw)
  To: Paul Rolland
  Cc: Larry Finger, Chaoming Li, John W. Linville, linux-wireless,
	linux-kernel
In-Reply-To: <20130723162659.5aa59750@tux.DEF.witbe.net>

2013/7/23 Paul Rolland <rol@witbe.net>:
> Hello Richard,
>
> If you still have the required HW and still would like a patch to remove
> that warning on your machine, could you please try the attached one ?
>
> I slightly reworked the original patch by moving the function
> rtl_lps_change_work_callback from pci.c to ps.c.
>
> I've successfully compiled that on my machine, but I have PCI set in
> my .config, so I'd like your feedback.
>
> Best,
> Paul

Hi Paul,

Well, I don't know why this patch didn't make it to 3.11-rc1, but it
seems that the patch you sent is the same as Larry's second patch :
https://lkml.org/lkml/2013/6/27/548

Best regards,
Richard.

^ permalink raw reply

* Re: rtl8192cu: slow path warning
From: Larry Finger @ 2013-07-23 15:05 UTC (permalink / raw)
  To: "Paul Rolland (ポール・ロラン)"
  Cc: Richard Genoud, Chaoming Li, John W. Linville, linux-wireless,
	linux-kernel
In-Reply-To: <20130723142907.53103aab@tux.DEF.witbe.net>

On 07/23/2013 07:29 AM, Paul Rolland (ポール・ロラン) wrote:
> Hello,
>
> On Thu, 27 Jun 2013 09:33:20 +0200
> Richard Genoud <richard.genoud@gmail.com> wrote:
>
>> Yes, of course, you can add my
>> Reported-by: Richard Genoud <richard.genoud@gmail.com>
>>
>> But the patch doesn't compile on my platform ( since I'm on ARM, I
>> haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) :
>>
>> ERROR: "rtl_lps_change_work_callback"
>> [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined!
>
> Is that the reason why this patch is not yet in 3.10.x or 3.11-rcY ?
> I'm running a 3.10.1 with USB dongle including 8192CU, and I can see this
> warning when the machine starts.
> I've check 3.10.1, 3.10.2 and 3.11-rc3 source code, but this fix is not
> there. Is there a different fix that went in in 3.10.2 or 3.11-rc?

The reason that patch is not in mainline is that it takes time. If you want to 
have it, you can get the official patch from 
http://marc.info/?l=linux-wireless&m=137242880222442&w=2, or you need to 
implement kernels from the wireless-testing git tree, where it was added on June 
28 as commit bcfb879. My original patch included the following note for John 
Linville:

"Ideally, this patch should be pushed to the 3.10 stream; however, at this late 
time that is not possible. Please push it for 3.11 and the Cc to stable will get 
it into 3.10.X."

As you see, it was marked with a Cc for Stable, and it will be propagated to 
3.10 when it gets incorporated by Linus. I think I have done all that I can do 
for now.

If you want to lobby Linus to get stuff accepted faster, that is your 
prerogative; however, I could not recommend that action, and I certainly will 
never do anything like that.

Larry


^ permalink raw reply

* Re: rtl8192cu: slow path warning
From: Paul Rolland @ 2013-07-23 15:49 UTC (permalink / raw)
  To: Larry Finger
  Cc: Richard Genoud, Chaoming Li, John W. Linville, linux-wireless,
	linux-kernel, rol
In-Reply-To: <51EE9BB6.8000501@lwfinger.net>

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

Hello Larry,

On Tue, 23 Jul 2013 10:05:26 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> The reason that patch is not in mainline is that it takes time. If you
> want to have it, you can get the official patch from 
> http://marc.info/?l=linux-wireless&m=137242880222442&w=2, or you need to 
> implement kernels from the wireless-testing git tree, where it was added
> on June 28 as commit bcfb879. My original patch included the following
> note for John Linville:
> 
> "Ideally, this patch should be pushed to the 3.10 stream; however, at
> this late time that is not possible. Please push it for 3.11 and the Cc
> to stable will get it into 3.10.X."
> 
> As you see, it was marked with a Cc for Stable, and it will be propagated
> to 3.10 when it gets incorporated by Linus. I think I have done all that
> I can do for now.
> 
> If you want to lobby Linus to get stuff accepted faster, that is your 
> prerogative; however, I could not recommend that action, and I certainly
> will never do anything like that.

Neither will I... I was just wondering and asking, nothing else, as I'm
also facing this warning. 

I'm glad to see the link you sent is presenting a patch that is the same as
the one I prepared. I'm going to use that while waiting for the patch to
hit mainline !

Thanks for replying, 
Best,
Paul


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* SMPS Action in AP mode?
From: Emmanuel Grumbach @ 2013-07-23 16:19 UTC (permalink / raw)
  To: linux-wireless

I am trying to figure out what would happen if, as an AP / GO, we
would send a SMPS action frame (switch to dynamic or even static)
mac80211 would honor the action frame and configure the driver to act
accordingly.

Does anyone have any experience with this?
The spec doesn't allow it specifically, but doesn't forbid it either,
so I guess we will have all kinds of behavior out there.
What about changing the caps in the beacon on the fly?

I prefer to ask instead of getting nasty bugs in interop...

Thanks!

Emmanuel Grumbach
egrumbach@gmail.com

^ permalink raw reply

* Re: [PATCH 1/2] regulatory: use correct regulatory initiator on wiphy register
From: Luis R. Rodriguez @ 2013-07-23 18:21 UTC (permalink / raw)
  To: Arik Nemtsov; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1374413809-26005-1-git-send-email-arik@wizery.com>

On Sun, Jul 21, 2013 at 6:36 AM, Arik Nemtsov <arik@wizery.com> wrote:
> The current regdomain was not always set by the core. This causes
> cards with a custom regulatory domain to ignore user initiated changes
> if done before the card was registered.
>
> Signed-off-by: Arik Nemtsov <arik@wizery.com>

Acked-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>

  Luis

^ permalink raw reply

* Re: Wake-On-Wireless and Deauthentication
From: greg.huber @ 2013-07-23 18:23 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Arend van Spriel, linux-wireless, daniel.wagner, Dan Williams
In-Reply-To: <51EABFCA.4060307@broadcom.com>

Not working yet, here's an update

I'm running wireshark wireless and can decode the packets between the test laptop
and the AP. Once authenticated I can see the WoW magic-packet on the air.

On the laptop, I disabled the NetworkManager and wpa_supplicant in systemd and
run wpa_supplicant manually with an appropriate conf file. I see the association
and authentication on wireshark.

Again I can also see WoW magic-packets on the air.

I now put the laptop in suspend to ram. Neither wireshark nor the AP log record
any disconnect, but I no longer see the WoW magic-packets on the air.

After resuming from the keyboard I see a 4-way authentication cycle, a deauth
and  another 4-way. I can see the WoW magic-packets again on wireshark.

Can anyone suggest what I might be doing wrong, or something else to try?
Also, if it's system normal to deauth on suspend, can WoW ever work??

I'll pull down the latest RC kernel and give it a try.

Thank You again for your assistance.

Greg

On 07/20/2013 12:50 PM, Arend van Spriel wrote:
> On 07/19/13 20:06, greg.huber wrote:
>> Thank you for your reply, I'm trying this now.
>>
>> Greg
>>
>> On 07/18/2013 09:38 PM, Luis R. Rodriguez wrote:
>>> On Wed, Jul 17, 2013 at 11:11 AM, greg.huber<greg.huber@carestream.com>  wrote:
>>>> I'm trying to get Wake-on-wireless working with an Atheros AR9462.
>>>> The problem I seem to be having is that there is a Deauth requested
>>>> when the system is suspended. Does anyone know how to keep the
>>>> association while suspended?? I'm using kernel 3.9.9.
>>>>
>>>> The log after waking (from keyboard)
>>>>
>>>> [  320.117062] wlp3s0: deauthenticating from 00:24:01:12:de:7a by local choice
>>>> (reason=3)
>>> Typical managers for networking will disassociate you (and therefore
>>> deauth first) prior to kicking the system to suspend. To test WoW you
>>> need to run the supplicant manually because as far as I can tell the
>>> GUI managers don't consider if WoW was enabled or not. In such a case
>>> that WoW was enabled the GUI managers should not send the
>>> deauth/disassoc.
>
> There has been recent commit, which may affect you:
>
> commit 8125696991194aacb1173b6e8196d19098b44e17
> Author: Stanislaw Gruszka <sgruszka@redhat.com>
> Date:   Thu Feb 28 10:55:25 2013 +0100
>
>     cfg80211/mac80211: disconnect on suspend
>
> It is mentioning something about wowlan so I am not sure whether it does. As
> you are on 3.9.9 I guess you do not have this commit.
>
> Regards,
> Arend
>
>


^ permalink raw reply

* Re: FUSB200 xhci issue
From: Christian Lamparter @ 2013-07-23 18:26 UTC (permalink / raw)
  To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee, USB list
In-Reply-To: <51EE0DC2.3030200@rempel-privat.de>

On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
> Am 22.07.2013 23:23, schrieb Christian Lamparter:
> > On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> >> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> >>> Hello!
> >>>
> >>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >>>> accidentally discovered that 9170 have it too. Are there any issue with
> >>>> usb-suspend + xhci controllers by you? Did you some how specially
> >>>> handled it?
> >>>
> >>> No, I haven't heard any complains about xhci + suspend. In fact,
> >>> it's working fine with the NEC xhci I have. I also have a AR9271
> >>> and AR7010, so if you want I could try if they survive a suspend
> >>> +resume cycle when attached.
> >>>
> >>> But, I do have a bug-report from someone else who has/had? problems
> >>> with carl9170 and xhci. If you want, you can get the details from:
> >>> "carl9170 A-MPDU transmit problem":
> >>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >>>
> >>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> >>> affected, but I don't know about Haswell):
> >>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
> >>
> >> Same situation is here - i have problem on Ivy Bridge.
> > (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
> > and AMD's new A6-1450 Temash and both xhci work. So I can't
> > do any proper comparisons like you.)
> >
> >> Steps to reproduce:
> >> - plug adapter. Module and firmware will be loaded
> >> - make sure usb autosupend is enabled. By default it is not! Use
> >> powertop or directly sysfs to enable autosuspend for this device
> >> - rmmod .... and wait some seconds until adapter is suspended and then
> >> modprobe ath9k_htc
> 
> >> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
> >> will report wrong size.. bigger as FIFO can handle. And only first ~40
> >> readet bytes will be actually OK.. all the rest of packet will be trashed.
> >
> > This is what happens with a WN721 (ar9271):
> >
> > [17619.597905] usbcore: deregistering interface driver ath9k_htc
> > [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
> > [17619.679602] ath9k_htc: Driver unloaded
> > <suspend>
> >
> > <resume>
> > [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
> > [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
> > [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
> > [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
> > [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
> > [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
> > [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
> > [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
> > [17667.573873] usbcore: registered new interface driver ath9k_htc
> > [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> > [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
> >
> > The driver loads, but there's no "wlanX" interface, no phyX interface
> > and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
> 
> So, it is exactly this bug.
> After firmware was loaded ath9k trying to set some registers. Since 
> command buffer is trashed it will write some nonsense to registers and 
> some times in wrong to wrong addresses. I have some patches to do crc 
> check of commands, to easy detect corrupted ones.
> 
> You reproduced it on NEC xhci? Is it possible to reproduce it in 
> carl9170?

Ok: That's dmesg of your scenario:

[  809.995966] usbcore: deregistering interface driver carl9170
<suspend>

<resume>
[  826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
[  826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
[  826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
[  826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
[  826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
[  826.432257] usbcore: registered new interface driver carl9170
[  826.433717] usb 2-2: driver   API: 1.9.8 2013-03-23 [1-1]
...
[  826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'

carl9170 is able to recover and the stick is working after autosuspend cycle.

> How about "carl9170 A-MPDU transmit problem"?
This was already isolated. The "AMPDU transmit problem" only happens with 
Ivy Bridge's xhci.

Regards

Christian 

^ permalink raw reply

* Re: [PATCH] Make BCMA_HOST_SOC depend on BCM47XX
From: Hauke Mehrtens @ 2013-07-23 21:36 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Rafał Miłecki, John W. Linville, linux-wireless
In-Reply-To: <CAGVrzcZfxei-p12+TDcJNg3TGSuJKfL3NvxvtWSfKEkxkZmYXw@mail.gmail.com>

On 07/23/2013 01:06 PM, Florian Fainelli wrote:
> 2013/7/23 Rafał Miłecki <zajec5@gmail.com>:
>> 2013/7/23 Hauke Mehrtens <hauke@hauke-m.de>:
>>> On 07/23/2013 04:31 AM, John W. Linville wrote:
>>>> From: "John W. Linville" <linville@tuxdriver.com>
>>>>
>>>> Otherwise, 'make allyesconfig' generates this:
>>>>
>>>>   CC [M]  drivers/net/ethernet/broadcom/bgmac.o
>>>> drivers/net/ethernet/broadcom/bgmac.c:19:27: fatal error:
>>>> bcm47xx_nvram.h: No such file or directory
>>>> compilation terminated.
>>>> make[4]: *** [drivers/net/ethernet/broadcom/bgmac.o] Error 1
>>>> make[3]: *** [drivers/net/ethernet/broadcom] Error 2
>>>> make[2]: *** [drivers/net/ethernet] Error 2
>>>> make[1]: *** [drivers/net] Error 2
>>>> make: *** [drivers] Error 2
>>>>
>>>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>>> ---
>>>>  drivers/bcma/Kconfig | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
>>>> index 7c081b3..a2bdab1 100644
>>>> --- a/drivers/bcma/Kconfig
>>>> +++ b/drivers/bcma/Kconfig
>>>> @@ -36,7 +36,7 @@ config BCMA_DRIVER_PCI_HOSTMODE
>>>>
>>>>  config BCMA_HOST_SOC
>>>>       bool "Support for BCMA in a SoC"
>>>> -     depends on BCMA
>>>> +     depends on BCMA && BCM47XX
>>>>       help
>>>>         Host interface for a Broadcom AIX bus directly mapped into
>>>>         the memory. This only works with the Broadcom SoCs from the
>>>>
>>> I think bgmac should depend on BCM47XX.
>>
>> Yeah, I'm wondering about that.
>>
>> It's bgmac that calls BCM47XX specific functions (nvram).
> 
> And this is bad, make that a platform_data callback or something like
> that such that there is no build-time dependency on nvram functions.

Ok, I will try that. I still have no idea how to handle the nvram stuff
properly with DT on arm. My current plan is to do this stuff properly
for arm and try to use most of the improvements also for mips.

>> On the other hand it doesn't make much sense to use BCMA_HOST_SOC on
>> anything else than BCM47XX, does it?
> 
> Hauke has been working on BCM53XX which is an ARM-based BCM47XX-like
> SoC, but that just means depends on (BCM47XX || ARCH_BCM53XX) then.

Yes preparing for adding arm support was the intention of this patch
series, it was some code which should not harm the mips part or any other.

Hauke

^ permalink raw reply

* Re: authsae, 'ath9k nohwcrypt=1' & AR9100
From: Etienne Champetier @ 2013-07-23 21:36 UTC (permalink / raw)
  To: linux-wireless, devel
In-Reply-To: <800088722.345614075.1374079656592.JavaMail.root@zimbra65-e11.priv.proxad.net>

Hi

Le 17/07/2013 18:47, etienne.champetier@free.fr a écrit :
> Hi
>
> I'm making some test with authsae on openrwt and for wr1043nd router (AR9100 wireless) i still need 'ath9k nohwcrypt=1'
> for the secure mesh to work when on another router (AR9280 wireless) i don't need it.
> Is it a drivers bug? or is it hardware?
>
> -Router A: wr1043nd (need nohwcrypt=1 option)
>   -AR9100 wireless
>   -authsae - 2013-06-25-e2f67612101dc83f2c459d8ddc75c34bc83e1e83 (https://github.com/cozybit/authsae/tree/e2f67612101dc83f2c459d8ddc75c34bc83e1e83)
>   -kmod-ath9k - 3.10.1+2013-06-27-1 (backports-20130617-4-ge3220f5)
>   -openwrt BB r37364
>
> -Router B: ubnt rspro
>   -AR9280 wireless
it's an AR9220 wireless (Mikrotik RB R52Hn), recognized as AR9280
>   -openwrt BB r37369 (same authsae/ath9k)
>
> Thanks in advance
> Etienne

This patch http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a549459c96ba99a691aa1cafeabdd327a7a2bfcf
make AR9160 and previous (AR9100) run in promiscuous mode (in order to catch all frames), does this influence hardware encryption (hwcrypt)?

Thanks in advance
Etienne


^ permalink raw reply

* [PATCH 1/2] staging: vt6656: Remove dead code macro ASSERT
From: Malcolm Priestley @ 2013-07-23 22:07 UTC (permalink / raw)
  To: gregkh; +Cc: linux-wireless

ASSERT is always defined as empty macro
because VIAWET_DEBUG is never defined.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
 drivers/staging/vt6656/baseband.c   | 1 -
 drivers/staging/vt6656/device_cfg.h | 8 --------
 drivers/staging/vt6656/dpc.c        | 6 ------
 drivers/staging/vt6656/main_usb.c   | 1 -
 drivers/staging/vt6656/rxtx.c       | 3 ---
 drivers/staging/vt6656/usbpipe.c    | 1 -
 6 files changed, 20 deletions(-)

diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c
index 33fa767..a14a6a0 100644
--- a/drivers/staging/vt6656/baseband.c
+++ b/drivers/staging/vt6656/baseband.c
@@ -680,7 +680,6 @@ BBuGetFrameTime(
     unsigned int uRate = 0;
 
     if (uRateIdx > RATE_54M) {
-        ASSERT(0);
         return 0;
     }
 
diff --git a/drivers/staging/vt6656/device_cfg.h b/drivers/staging/vt6656/device_cfg.h
index ea66b97..ad1fbf6 100644
--- a/drivers/staging/vt6656/device_cfg.h
+++ b/drivers/staging/vt6656/device_cfg.h
@@ -83,16 +83,8 @@ typedef enum  _chip_type {
 } CHIP_TYPE, *PCHIP_TYPE;
 
 #ifdef VIAWET_DEBUG
-#define ASSERT(x) { \
-    if (!(x)) { \
-	printk(KERN_ERR "assertion %s failed: file %s line %d\n", #x, \
-        __FUNCTION__, __LINE__);\
-	*(int *) 0 = 0;		\
-    } \
-}
 #define DBG_PORT80(value)                   outb(value, 0x80)
 #else
-#define ASSERT(x)
 #define DBG_PORT80(value)
 #endif
 
diff --git a/drivers/staging/vt6656/dpc.c b/drivers/staging/vt6656/dpc.c
index 7ec166a..4bc362f 100644
--- a/drivers/staging/vt6656/dpc.c
+++ b/drivers/staging/vt6656/dpc.c
@@ -314,7 +314,6 @@ int RXbBulkInProcessData(struct vnt_private *pDevice, PRCB pRCB,
          (BytesToIndicate < (*pwPLCP_Length)) ) {
 
         DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"Wrong PLCP Length %x\n", (int) *pwPLCP_Length);
-        ASSERT(0);
         return false;
     }
     for ( ii=RATE_1M;ii<MAX_RATE;ii++) {
@@ -1347,7 +1346,6 @@ void RXvWorkItem(struct vnt_private *pDevice)
             (pDevice->NumRecvFreeList != 0) ) {
         pRCB = pDevice->FirstRecvFreeList;
         pDevice->NumRecvFreeList--;
-        ASSERT(pRCB);// cannot be NULL
         DequeueRCB(pDevice->FirstRecvFreeList, pDevice->LastRecvFreeList);
         ntStatus = PIPEnsBulkInUsbRead(pDevice, pRCB);
     }
@@ -1362,9 +1360,6 @@ void RXvFreeRCB(PRCB pRCB, int bReAllocSkb)
 
     DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"---->RXvFreeRCB\n");
 
-    ASSERT(!pRCB->Ref);     // should be 0
-    ASSERT(pRCB->pDevice);  // shouldn't be NULL
-
 	if (bReAllocSkb == false) {
 		kfree_skb(pRCB->skb);
 		bReAllocSkb = true;
@@ -1411,7 +1406,6 @@ void RXvMngWorkItem(struct vnt_private *pDevice)
         if(!pRCB){
             break;
         }
-        ASSERT(pRCB);// cannot be NULL
         pRxPacket = &(pRCB->sMngPacket);
 	vMgrRxManagePacket(pDevice, &pDevice->vnt_mgmt, pRxPacket);
         pRCB->Ref--;
diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index 3a3fdc5..0c9e60f 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -925,7 +925,6 @@ int device_alloc_frag_buf(struct vnt_private *pDevice,
     pDeF->skb = dev_alloc_skb((int)pDevice->rx_buf_sz);
     if (pDeF->skb == NULL)
         return false;
-    ASSERT(pDeF->skb);
     pDeF->skb->dev = pDevice->dev;
 
     return true;
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 1879b39..6e5e2b7 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -545,7 +545,6 @@ static u32 s_uGetDataDuration(struct vnt_private *pDevice, u8 byDurType,
         break;
     }
 
-	ASSERT(false);
 	return 0;
 }
 
@@ -1482,8 +1481,6 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
         memcpy((pbyPayloadHead + cb802_1_H_len), ((u8 *)psEthHeader) + ETH_HLEN, uSkbPacketLen - ETH_HLEN);
     }
 
-    ASSERT(uLength == cbNdisBodySize);
-
     if ((bNeedEncryption == true) && (pTransmitKey != NULL) && (pTransmitKey->byCipherSuite == KEY_CTL_TKIP)) {
 
         ///////////////////////////////////////////////////////////////////
diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index a9d50ba..8cd5685 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -638,7 +638,6 @@ static void s_nsBulkOutIoCompleteWrite(struct urb *urb)
     // The context given to IoSetCompletionRoutine is an USB_CONTEXT struct
     //
     pContext = (PUSB_SEND_CONTEXT) urb->context;
-    ASSERT( NULL != pContext );
 
     pDevice = pContext->pDevice;
     ContextType = pContext->Type;
-- 
1.8.1.2





^ permalink raw reply related

* QCA vs community contributions to QCA drivers
From: Luis R. Rodriguez @ 2013-07-23 22:09 UTC (permalink / raw)
  To: linux-wireless

Here's a google drive spreadsheet anyone can view of QCA vs community
contributions to QCA device drivers:

https://docs.google.com/spreadsheet/ccc?key=0AtNdeeyGJEJ7dG45U2xrZldlQm80Nlg5QzEwUmtNUGc

If you'd like to contribute feel free to drop me a line or contact of
the other QCA device driver maintainers.

  Luis

^ permalink raw reply

* [PATCH 2/2] staging: vt6656: remove dead code DBG_PORT80/VIAWET_DEBUG
From: Malcolm Priestley @ 2013-07-23 22:10 UTC (permalink / raw)
  To: gregkh; +Cc: linux-wireless


DBG_PORT80 is always defined as empty macro
because VIAWET_DEBUG is never defined. Remove
it and VIAWET_DEBUG.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>

---
 drivers/staging/vt6656/device_cfg.h | 6 ------
 drivers/staging/vt6656/wmgr.c       | 2 --
 2 files changed, 8 deletions(-)

diff --git a/drivers/staging/vt6656/device_cfg.h b/drivers/staging/vt6656/device_cfg.h
index ad1fbf6..a97f7bb 100644
--- a/drivers/staging/vt6656/device_cfg.h
+++ b/drivers/staging/vt6656/device_cfg.h
@@ -82,10 +82,4 @@ typedef enum  _chip_type {
     VT3184 = 1
 } CHIP_TYPE, *PCHIP_TYPE;
 
-#ifdef VIAWET_DEBUG
-#define DBG_PORT80(value)                   outb(value, 0x80)
-#else
-#define DBG_PORT80(value)
-#endif
-
 #endif
diff --git a/drivers/staging/vt6656/wmgr.c b/drivers/staging/vt6656/wmgr.c
index 6d1ff5e..b6cbd13 100644
--- a/drivers/staging/vt6656/wmgr.c
+++ b/drivers/staging/vt6656/wmgr.c
@@ -751,7 +751,6 @@ static void s_vMgrRxAssocResponse(struct vnt_private *pDevice,
 	    || (sFrame.pwStatus == NULL)
 	    || (sFrame.pwAid == NULL)
 	    || (sFrame.pSuppRates == NULL)) {
-		DBG_PORT80(0xCC);
 		return;
         }
 
@@ -3750,7 +3749,6 @@ static void s_vMgrRxProbeResponse(struct vnt_private *pDevice,
 
 	DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "Probe resp:Fail addr:[%p]\n",
 		pRxPacket->p80211Header);
-	DBG_PORT80(0xCC);
 	return;
     }
 
-- 
1.8.1.2




^ permalink raw reply related

* [PATCH 1/5] ath9k: Add information about AR9285 diversity
From: Sujith Manoharan @ 2013-07-24  8:21 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless

From: Sujith Manoharan <c_manoha@qca.qualcomm.com>

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/antenna.c | 39 ++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c
index 664844c..a05fa18 100644
--- a/drivers/net/wireless/ath/ath9k/antenna.c
+++ b/drivers/net/wireless/ath/ath9k/antenna.c
@@ -16,6 +16,45 @@
 
 #include "ath9k.h"
 
+/*
+ * AR9285
+ * ======
+ *
+ * EEPROM has 2 4-bit fields containing the card configuration.
+ *
+ * antdiv_ctl1:
+ * ------------
+ * bb_enable_ant_div_lnadiv : 1
+ * bb_ant_div_alt_gaintb    : 1
+ * bb_ant_div_main_gaintb   : 1
+ * bb_enable_ant_fast_div   : 1
+ *
+ * antdiv_ctl2:
+ * -----------
+ * bb_ant_div_alt_lnaconf  : 2
+ * bb_ant_div_main_lnaconf : 2
+ *
+ * The EEPROM bits are used as follows:
+ * ------------------------------------
+ *
+ * bb_enable_ant_div_lnadiv      - Enable LNA path rx antenna diversity/combining.
+ *                                 Set in AR_PHY_MULTICHAIN_GAIN_CTL.
+ *
+ * bb_ant_div_[alt/main]_gaintb  - 0 -> Antenna config Alt/Main uses gaintable 0
+ *                                 1 -> Antenna config Alt/Main uses gaintable 1
+ *                                 Set in AR_PHY_MULTICHAIN_GAIN_CTL.
+ *
+ * bb_enable_ant_fast_div        - Enable fast antenna diversity.
+ *                                 Set in AR_PHY_CCK_DETECT.
+ *
+ * bb_ant_div_[alt/main]_lnaconf - Alt/Main LNA diversity/combining input config.
+ *                                 Set in AR_PHY_MULTICHAIN_GAIN_CTL.
+ *                                 10=LNA1
+ *                                 01=LNA2
+ *                                 11=LNA1+LNA2
+ *                                 00=LNA1-LNA2
+ */
+
 static inline bool ath_is_alt_ant_ratio_better(int alt_ratio, int maxdelta,
 					       int mindelta, int main_rssi_avg,
 					       int alt_rssi_avg, int pkt_count)
-- 
1.8.3.3


^ permalink raw reply related

* [PATCH 3/5] ath9k: Cleanup BT/WLAN RX diversity
From: Sujith Manoharan @ 2013-07-24  8:21 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless
In-Reply-To: <1374654090-24408-1-git-send-email-sujith@msujith.org>

From: Sujith Manoharan <c_manoha@qca.qualcomm.com>

For single-chain WLAN+BT cards, the BT antenna can be used for
WLAN RX when the BT interface is disabled. Rename the modparam
"antenna_diversity" to "bt_ant_diversity" to clarify this.

Also, there is no need to check if btcoex is disabled to enable
WLAN/BT RX diversity.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath.h           |  2 +-
 drivers/net/wireless/ath/ath9k/antenna.c |  2 +-
 drivers/net/wireless/ath/ath9k/debug.c   | 32 ++++++++++++++++----------------
 drivers/net/wireless/ath/ath9k/init.c    | 30 +++++++++++++++++++++++-------
 4 files changed, 41 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index daeafef..e0ba7cd 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -159,7 +159,7 @@ struct ath_common {
 
 	bool btcoex_enabled;
 	bool disable_ani;
-	bool antenna_diversity;
+	bool bt_ant_diversity;
 };
 
 struct sk_buff *ath_rxbuf_alloc(struct ath_common *common,
diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c
index a05fa18..6560dcb 100644
--- a/drivers/net/wireless/ath/ath9k/antenna.c
+++ b/drivers/net/wireless/ath/ath9k/antenna.c
@@ -831,6 +831,6 @@ void ath_ant_comb_update(struct ath_softc *sc)
 
 	ath9k_hw_antdiv_comb_conf_set(ah, &div_ant_conf);
 
-	if (common->antenna_diversity)
+	if (common->bt_ant_diversity)
 		ath9k_hw_antctrl_shared_chain_lnadiv(ah, true);
 }
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 87454f6..5639c5b 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -270,25 +270,25 @@ static const struct file_operations fops_ani = {
 	.llseek = default_llseek,
 };
 
-static ssize_t read_file_ant_diversity(struct file *file, char __user *user_buf,
-				       size_t count, loff_t *ppos)
+static ssize_t read_file_bt_ant_diversity(struct file *file, char __user *user_buf,
+					  size_t count, loff_t *ppos)
 {
 	struct ath_softc *sc = file->private_data;
 	struct ath_common *common = ath9k_hw_common(sc->sc_ah);
 	char buf[32];
 	unsigned int len;
 
-	len = sprintf(buf, "%d\n", common->antenna_diversity);
+	len = sprintf(buf, "%d\n", common->bt_ant_diversity);
 	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
 }
 
-static ssize_t write_file_ant_diversity(struct file *file,
-					const char __user *user_buf,
-					size_t count, loff_t *ppos)
+static ssize_t write_file_bt_ant_diversity(struct file *file,
+					   const char __user *user_buf,
+					   size_t count, loff_t *ppos)
 {
 	struct ath_softc *sc = file->private_data;
 	struct ath_common *common = ath9k_hw_common(sc->sc_ah);
-	unsigned long antenna_diversity;
+	unsigned long bt_ant_diversity;
 	char buf[32];
 	ssize_t len;
 
@@ -300,22 +300,22 @@ static ssize_t write_file_ant_diversity(struct file *file,
 		goto exit;
 
 	buf[len] = '\0';
-	if (kstrtoul(buf, 0, &antenna_diversity))
+	if (kstrtoul(buf, 0, &bt_ant_diversity))
 		return -EINVAL;
 
-	common->antenna_diversity = !!antenna_diversity;
+	common->bt_ant_diversity = !!bt_ant_diversity;
 	ath9k_ps_wakeup(sc);
 	ath_ant_comb_update(sc);
-	ath_dbg(common, CONFIG, "Antenna diversity: %d\n",
-		common->antenna_diversity);
+	ath_dbg(common, CONFIG, "BT/WLAN RX Antenna diversity: %d\n",
+		common->bt_ant_diversity);
 	ath9k_ps_restore(sc);
 exit:
 	return count;
 }
 
-static const struct file_operations fops_ant_diversity = {
-	.read = read_file_ant_diversity,
-	.write = write_file_ant_diversity,
+static const struct file_operations fops_bt_ant_diversity = {
+	.read = read_file_bt_ant_diversity,
+	.write = write_file_bt_ant_diversity,
 	.open = simple_open,
 	.owner = THIS_MODULE,
 	.llseek = default_llseek,
@@ -1814,8 +1814,8 @@ int ath9k_init_debug(struct ath_hw *ah)
 			   sc->debug.debugfs_phy, &sc->sc_ah->gpio_mask);
 	debugfs_create_u32("gpio_val", S_IRUSR | S_IWUSR,
 			   sc->debug.debugfs_phy, &sc->sc_ah->gpio_val);
-	debugfs_create_file("diversity", S_IRUSR | S_IWUSR,
-			    sc->debug.debugfs_phy, sc, &fops_ant_diversity);
+	debugfs_create_file("bt_ant_diversity", S_IRUSR | S_IWUSR,
+			    sc->debug.debugfs_phy, sc, &fops_bt_ant_diversity);
 #ifdef CONFIG_ATH9K_BTCOEX_SUPPORT
 	debugfs_create_file("btcoex", S_IRUSR, sc->debug.debugfs_phy, sc,
 			    &fops_btcoex);
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 16f8b20..d27395f 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -53,9 +53,9 @@ static int ath9k_btcoex_enable;
 module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
 MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
 
-static int ath9k_enable_diversity;
-module_param_named(enable_diversity, ath9k_enable_diversity, int, 0444);
-MODULE_PARM_DESC(enable_diversity, "Enable Antenna diversity for AR9565");
+static int ath9k_bt_ant_diversity;
+module_param_named(bt_antenna_diversity, ath9k_bt_ant_diversity, int, 0444);
+MODULE_PARM_DESC(bt_antenna_diversity, "Use BT antenna for WLAN RX diversity");
 
 bool is_ath9k_unloaded;
 /* We use the hw_value as an index into our private channel structure */
@@ -631,11 +631,27 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
 	ath9k_init_platform(sc);
 
 	/*
-	 * Enable Antenna diversity only when BTCOEX is disabled
-	 * and the user manually requests the feature.
+	 * Enable WLAN RX Antenna diversity for WLAN/BT combo
+	 * chips only when the user manually requests the feature.
+	 *
+	 * The BT antenna can be used for WLAN RX when the
+	 * BT interface is disabled. Currently, there is no
+	 * mechanism in the kernel to pass such information
+	 * between the WLAN and BT subsystems. The user has
+	 * to make sure that the BT card is disabled when enabling
+	 * WLAN RX diversity.
+	 *
+	 * Cards which can use this feature are:
+	 *
+	 * WB225 - AR9485 + AR3012
+	 * WB335 - AR9565 (WLAN+BT Combo SoC).
+	 *
+	 * Diversity combining is available for WB225 and WB335.
+	 * WB195 which is a AR9285 + AR3011 card doesn't have
+	 * this feature.
 	 */
-	if (!common->btcoex_enabled && ath9k_enable_diversity)
-		common->antenna_diversity = 1;
+	if (ath9k_bt_ant_diversity)
+		common->bt_ant_diversity = 1;
 
 	spin_lock_init(&common->cc_lock);
 
-- 
1.8.3.3


^ permalink raw reply related

* [PATCH 4/5] ath9k: Add a HW capability for WLAN/BT RX diversity
From: Sujith Manoharan @ 2013-07-24  8:21 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless
In-Reply-To: <1374654090-24408-1-git-send-email-sujith@msujith.org>

From: Sujith Manoharan <c_manoha@qca.qualcomm.com>

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/ath9k.h |  9 +++++----
 drivers/net/wireless/ath/ath9k/hw.h    |  1 +
 drivers/net/wireless/ath/ath9k/init.c  | 13 +++++++++++--
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 76e38d3..2992fd0 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -624,10 +624,11 @@ void ath_ant_comb_update(struct ath_softc *sc);
 /* Main driver core */
 /********************/
 
-#define ATH9K_PCI_CUS198 0x0001
-#define ATH9K_PCI_CUS230 0x0002
-#define ATH9K_PCI_CUS217 0x0004
-#define ATH9K_PCI_WOW    0x0008
+#define ATH9K_PCI_CUS198     0x0001
+#define ATH9K_PCI_CUS230     0x0002
+#define ATH9K_PCI_CUS217     0x0004
+#define ATH9K_PCI_WOW        0x0008
+#define ATH9K_PCI_BT_ANT_DIV 0x0010
 
 /*
  * Default cache line size, in bytes.
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index fd009e5..4ab8f58 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -248,6 +248,7 @@ enum ath9k_hw_caps {
 	ATH9K_HW_WOW_DEVICE_CAPABLE		= BIT(17),
 	ATH9K_HW_CAP_PAPRD			= BIT(18),
 	ATH9K_HW_CAP_FCC_BAND_SWITCH		= BIT(19),
+	ATH9K_HW_CAP_BT_ANT_DIV			= BIT(20),
 };
 
 /*
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index d27395f..defed26 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -516,6 +516,7 @@ static void ath9k_init_misc(struct ath_softc *sc)
 static void ath9k_init_platform(struct ath_softc *sc)
 {
 	struct ath_hw *ah = sc->sc_ah;
+	struct ath9k_hw_capabilities *pCap = &ah->caps;
 	struct ath_common *common = ath9k_hw_common(ah);
 
 	if (common->bus_ops->ath_bus_type != ATH_PCI)
@@ -529,8 +530,14 @@ static void ath9k_init_platform(struct ath_softc *sc)
 		ath_info(common, "Set parameters for %s\n",
 			 (sc->driver_data & ATH9K_PCI_CUS198) ?
 			 "CUS198" : "CUS230");
-	} else if (sc->driver_data & ATH9K_PCI_CUS217) {
+	}
+
+	if (sc->driver_data & ATH9K_PCI_CUS217)
 		ath_info(common, "CUS217 card detected\n");
+
+	if (sc->driver_data & ATH9K_PCI_BT_ANT_DIV) {
+		pCap->hw_caps |= ATH9K_HW_CAP_BT_ANT_DIV;
+		ath_info(common, "Enable BT/WLAN RX diversity\n");
 	}
 }
 
@@ -583,6 +590,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
 			    const struct ath_bus_ops *bus_ops)
 {
 	struct ath9k_platform_data *pdata = sc->dev->platform_data;
+	struct ath9k_hw_capabilities *pCap;
 	struct ath_hw *ah = NULL;
 	struct ath_common *common;
 	int ret = 0, i;
@@ -600,6 +608,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
 	ah->reg_ops.rmw = ath9k_reg_rmw;
 	atomic_set(&ah->intr_ref_cnt, -1);
 	sc->sc_ah = ah;
+	pCap = &ah->caps;
 
 	sc->dfs_detector = dfs_pattern_detector_init(ah, NL80211_DFS_UNSET);
 
@@ -650,7 +659,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
 	 * WB195 which is a AR9285 + AR3011 card doesn't have
 	 * this feature.
 	 */
-	if (ath9k_bt_ant_diversity)
+	if (ath9k_bt_ant_diversity && (pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV))
 		common->bt_ant_diversity = 1;
 
 	spin_lock_init(&common->cc_lock);
-- 
1.8.3.3


^ permalink raw reply related

* [PATCH 2/5] ath9k: Print LNA combining mode during init
From: Sujith Manoharan @ 2013-07-24  8:21 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless
In-Reply-To: <1374654090-24408-1-git-send-email-sujith@msujith.org>

From: Sujith Manoharan <c_manoha@qca.qualcomm.com>

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/hw.c | 24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index d55d97c..8bd602c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2559,34 +2559,28 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
 	if (AR_SREV_9287_11_OR_LATER(ah) || AR_SREV_9271(ah))
 		pCap->hw_caps |= ATH9K_HW_CAP_SGI_20;
 
-	if (AR_SREV_9285(ah))
+	if (AR_SREV_9285(ah)) {
 		if (ah->eep_ops->get_eeprom(ah, EEP_MODAL_VER) >= 3) {
 			ant_div_ctl1 =
 				ah->eep_ops->get_eeprom(ah, EEP_ANT_DIV_CTL1);
-			if ((ant_div_ctl1 & 0x1) && ((ant_div_ctl1 >> 3) & 0x1))
+			if ((ant_div_ctl1 & 0x1) && ((ant_div_ctl1 >> 3) & 0x1)) {
 				pCap->hw_caps |= ATH9K_HW_CAP_ANT_DIV_COMB;
+				ath_info(common, "Enable LNA combining\n");
+			}
 		}
+	}
+
 	if (AR_SREV_9300_20_OR_LATER(ah)) {
 		if (ah->eep_ops->get_eeprom(ah, EEP_CHAIN_MASK_REDUCE))
 			pCap->hw_caps |= ATH9K_HW_CAP_APM;
 	}
 
-
 	if (AR_SREV_9330(ah) || AR_SREV_9485(ah) || AR_SREV_9565(ah)) {
 		ant_div_ctl1 = ah->eep_ops->get_eeprom(ah, EEP_ANT_DIV_CTL1);
-		/*
-		 * enable the diversity-combining algorithm only when
-		 * both enable_lna_div and enable_fast_div are set
-		 *		Table for Diversity
-		 * ant_div_alt_lnaconf		bit 0-1
-		 * ant_div_main_lnaconf		bit 2-3
-		 * ant_div_alt_gaintb		bit 4
-		 * ant_div_main_gaintb		bit 5
-		 * enable_ant_div_lnadiv	bit 6
-		 * enable_ant_fast_div		bit 7
-		 */
-		if ((ant_div_ctl1 >> 0x6) == 0x3)
+		if ((ant_div_ctl1 >> 0x6) == 0x3) {
 			pCap->hw_caps |= ATH9K_HW_CAP_ANT_DIV_COMB;
+			ath_info(common, "Enable LNA combining\n");
+		}
 	}
 
 	if (ath9k_hw_dfs_tested(ah))
-- 
1.8.3.3


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox