* 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: 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: 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: [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
* [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: 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
* 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
* [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] 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] 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: 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
* Pull request: ath-current 20130723
From: Kalle Valo @ 2013-07-23 9:46 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, ath6kl-devel, ath10k
Hi John,
here's an ath6kl and ath10k pull request for 3.11-rc series.
Geert Uytterhoeven fixed an ath10k build problem when NO_DMA=y. I added
a missing MAINTAINERS entry for ath10k and updated ath6kl git tree
location.
Please let me know if there are any problems, or if you prefer me to
send them through wireless-next instead.
Kalle
The following changes since commit 64b6f46f1141ad938e354f37af62e28da972e8eb:
ath9k_hw: Fix multicast search for AR9002 family (2013-07-18 16:22:00 -0400)
are available in the git repository at:
git://github.com/kvalo/ath.git for-linville-current
for you to fetch changes up to 58cfb681bffb43654776a218a087028ff425ba9e:
MAINTAINERS: update ath6kl git location (2013-07-22 12:26:12 +0300)
----------------------------------------------------------------
Geert Uytterhoeven (1):
ath10k: ATH10K should depend on HAS_DMA
Kalle Valo (2):
MAINTAINERS: add ath10k
MAINTAINERS: update ath6kl git location
MAINTAINERS | 10 +++++++++-
drivers/net/wireless/ath/ath10k/Kconfig | 2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/2] MAINTAINERS: ath10k and ath6kl updates
From: Kalle Valo @ 2013-07-23 9:26 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k
In-Reply-To: <20130722093113.26562.11543.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> here few patches for MAINTAINERS. If they are ok I'll add them to ath.git and
> send a pull request to John.
Applied to ath-current branch of ath.git.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/4] ath10k: fixes
From: Kalle Valo @ 2013-07-23 8:47 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374495211-20353-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> Here are some fixes for ath10k. The rts threshold
> patch addresses my mistake in commit
> 9aeb6fe53d1f0d6e58658484ce9ad7b59f0ef16b which
> caused rts to be always enabled causing throughput
> issues in some cases.
>
> v2: first patch is split now into two as requested
> rebased on top of latest github master branch
>
>
> Michal Kazior (4):
> ath10k: prevent HTC from being used after stopping
> ath10k: don't reset HTC endpoints unnecessarily
> ath10k: fix memleak in mac setup
> ath10k: fix rts/fragmentation threshold setup
All four applied, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 2/4] ath10k: don't reset HTC endpoints unnecessarily
From: Kalle Valo @ 2013-07-23 8:46 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374495211-20353-3-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Endpoints are re-initialized upon HTC start anyway
> so there's no need to do that twice in case of
> restarting HTC (i.e. in case of hardware
> recovery).
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
This is much better, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4] ath10k: create debugfs interface to trigger fw crash
From: Kalle Valo @ 2013-07-23 8:02 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374494931-18913-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This can be useful for testing. To perform a
> forced firmware crash write 'crash' to
> 'simulate_fw_crash' debugfs file. E.g.
>
> echo crash > /sys/kernel/debug/ieee80211/phy1/ath10k/simulate_fw_crash
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
> ---
> v3: return an appropriate errno instead of using ath10k_warn()
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Make BCMA_HOST_SOC depend on BCM47XX
From: Rafał Miłecki @ 2013-07-23 7:50 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: John W. Linville, linux-wireless
In-Reply-To: <51EE3018.4000507@hauke-m.de>
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).
On the other hand it doesn't make much sense to use BCMA_HOST_SOC on
anything else than BCM47XX, does it?
--
Rafał
^ permalink raw reply
* Re: [PATCH] Make BCMA_HOST_SOC depend on BCM47XX
From: Hauke Mehrtens @ 2013-07-23 7:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Rafał Miłecki
In-Reply-To: <1374546675-384-1-git-send-email-linville@tuxdriver.com>
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.
Hauke
^ permalink raw reply
* Re: [PATCH] ath: wil6210: Fix build error
From: Luis R. Rodriguez @ 2013-07-23 7:13 UTC (permalink / raw)
To: Vladimir Kondratiev; +Cc: linux-wireless
In-Reply-To: <6487488.19IqyPtizJ@lx-vladimir>
On Tue, Jul 23, 2013 at 12:06 AM, Vladimir Kondratiev
<qca_vkondrat@qca.qualcomm.com> wrote:
> On Monday, July 22, 2013 09:17:01 AM Luis R. Rodriguez wrote:
>> On Sun, Jul 21, 2013 at 10:06:31AM +0300, Vladimir Kondratiev wrote:
>> > Hmm, I have no warning for this with neither 3.10 nor 3.11 kernel version; but
>> > patch is correct, and here is my
>> > Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
>>
>> If you agree with a patch you don't say you Sign-off-by it as well,
>> you say Acked-by. The Signed-off-by tag has a very specific meaning
>> from development to a maintainer's hands, and its definition is on
>> the Developer Certificate or Origin.
>>
>> So in this case Acked-by is better.
>>
>> Luis
>
> <drop most of CC>
>
> I thought that I need to add Signed-off-by: as driver's maintainer, because
> (quote Documentation/SubmittingPatches):
> ---
> The Signed-off-by: tag indicates that the signer was involved in the
> development of the patch, or that he/she was in the patch's delivery path.
> ---
>
> This is similar to other maintainers adding its Signed-off-by:.
> Or, is driver's maintainer an exception from the rule quoted above?
If you had a git tree, sure, otherwise not in this case.
Luis
^ permalink raw reply
* Re: [PATCH] ath: wil6210: Fix build error
From: Vladimir Kondratiev @ 2013-07-23 7:06 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <20130722161554.GR17130@pogo>
On Monday, July 22, 2013 09:17:01 AM Luis R. Rodriguez wrote:
> On Sun, Jul 21, 2013 at 10:06:31AM +0300, Vladimir Kondratiev wrote:
> > Hmm, I have no warning for this with neither 3.10 nor 3.11 kernel version; but
> > patch is correct, and here is my
> > Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
>
> If you agree with a patch you don't say you Sign-off-by it as well,
> you say Acked-by. The Signed-off-by tag has a very specific meaning
> from development to a maintainer's hands, and its definition is on
> the Developer Certificate or Origin.
>
> So in this case Acked-by is better.
>
> Luis
<drop most of CC>
I thought that I need to add Signed-off-by: as driver's maintainer, because
(quote Documentation/SubmittingPatches):
---
The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.
---
This is similar to other maintainers adding its Signed-off-by:.
Or, is driver's maintainer an exception from the rule quoted above?
Thanks, Vladimir
^ permalink raw reply
* [PATCH] mwifiex: Add missing endian conversion.
From: Tomasz Moń @ 2013-07-23 5:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, bzhao, Tomasz Moń
Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.
Signed-off-by: Tomasz Moń <desowin@gmail.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/sdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index 5ee5ed0..c9f3ecf 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1625,8 +1625,8 @@ static int mwifiex_sdio_host_to_card(struct mwifiex_adapter *adapter,
/* Allocate buffer and copy payload */
blk_size = MWIFIEX_SDIO_BLOCK_SIZE;
buf_block_len = (pkt_len + blk_size - 1) / blk_size;
- *(u16 *) &payload[0] = (u16) pkt_len;
- *(u16 *) &payload[2] = type;
+ *(__le16 *)&payload[0] = cpu_to_le16((u16)pkt_len);
+ *(__le16 *)&payload[2] = cpu_to_le16(type);
/*
* This is SDIO specific header
--
1.8.3.msysgit.0
^ permalink raw reply related
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-07-23 4:59 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Sarah Sharp, Seth Forshee, USB list
In-Reply-To: <3155156.7uKpoiQrxp@blech>
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? How about "carl9170 A-MPDU transmit problem"?
I noticed one more workaround. By reducing skb size to 64byte for EP4,
this bug can be avoided. But, since it works on EHCI, and on XHCI before
usb-suspend, i would prefer to fix host controller driver.
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH] Make BCMA_HOST_SOC depend on BCM47XX
From: John W. Linville @ 2013-07-23 2:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Rafał Miłecki, John W. Linville
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
--
1.8.1.4
^ permalink raw reply related
* [PATCH 19/21] mwifiex: code rearrangement in sdio.c
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Amitkumar Karwar <akarwar@marvell.com>
Some function definitions are moved to appropriate place
to avoid forward declarations.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/sdio.c | 211 ++++++++++++++++++------------------
1 file changed, 104 insertions(+), 107 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index c32a735..1eb5efa1 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -50,9 +50,6 @@ static struct mwifiex_if_ops sdio_ops;
static struct semaphore add_remove_card_sem;
-static int mwifiex_sdio_resume(struct device *dev);
-static void mwifiex_sdio_interrupt(struct sdio_func *func);
-
/*
* SDIO probe.
*
@@ -113,6 +110,51 @@ mwifiex_sdio_probe(struct sdio_func *func, const struct sdio_device_id *id)
}
/*
+ * SDIO resume.
+ *
+ * Kernel needs to suspend all functions separately. Therefore all
+ * registered functions must have drivers with suspend and resume
+ * methods. Failing that the kernel simply removes the whole card.
+ *
+ * If already not resumed, this function turns on the traffic and
+ * sends a host sleep cancel request to the firmware.
+ */
+static int mwifiex_sdio_resume(struct device *dev)
+{
+ struct sdio_func *func = dev_to_sdio_func(dev);
+ struct sdio_mmc_card *card;
+ struct mwifiex_adapter *adapter;
+ mmc_pm_flag_t pm_flag = 0;
+
+ if (func) {
+ pm_flag = sdio_get_host_pm_caps(func);
+ card = sdio_get_drvdata(func);
+ if (!card || !card->adapter) {
+ pr_err("resume: invalid card or adapter\n");
+ return 0;
+ }
+ } else {
+ pr_err("resume: sdio_func is not specified\n");
+ return 0;
+ }
+
+ adapter = card->adapter;
+
+ if (!adapter->is_suspended) {
+ dev_warn(adapter->dev, "device already resumed\n");
+ return 0;
+ }
+
+ adapter->is_suspended = false;
+
+ /* Disable Host Sleep */
+ mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
+ MWIFIEX_ASYNC_CMD);
+
+ return 0;
+}
+
+/*
* SDIO remove.
*
* This function removes the interface and frees up the card structure.
@@ -212,51 +254,6 @@ static int mwifiex_sdio_suspend(struct device *dev)
return ret;
}
-/*
- * SDIO resume.
- *
- * Kernel needs to suspend all functions separately. Therefore all
- * registered functions must have drivers with suspend and resume
- * methods. Failing that the kernel simply removes the whole card.
- *
- * If already not resumed, this function turns on the traffic and
- * sends a host sleep cancel request to the firmware.
- */
-static int mwifiex_sdio_resume(struct device *dev)
-{
- struct sdio_func *func = dev_to_sdio_func(dev);
- struct sdio_mmc_card *card;
- struct mwifiex_adapter *adapter;
- mmc_pm_flag_t pm_flag = 0;
-
- if (func) {
- pm_flag = sdio_get_host_pm_caps(func);
- card = sdio_get_drvdata(func);
- if (!card || !card->adapter) {
- pr_err("resume: invalid card or adapter\n");
- return 0;
- }
- } else {
- pr_err("resume: sdio_func is not specified\n");
- return 0;
- }
-
- adapter = card->adapter;
-
- if (!adapter->is_suspended) {
- dev_warn(adapter->dev, "device already resumed\n");
- return 0;
- }
-
- adapter->is_suspended = false;
-
- /* Disable Host Sleep */
- mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
- MWIFIEX_ASYNC_CMD);
-
- return 0;
-}
-
/* Device ID for SD8786 */
#define SDIO_DEVICE_ID_MARVELL_8786 (0x9116)
/* Device ID for SD8787 */
@@ -707,6 +704,65 @@ static void mwifiex_sdio_disable_host_int(struct mwifiex_adapter *adapter)
}
/*
+ * This function reads the interrupt status from card.
+ */
+static void mwifiex_interrupt_status(struct mwifiex_adapter *adapter)
+{
+ struct sdio_mmc_card *card = adapter->card;
+ u8 sdio_ireg;
+ unsigned long flags;
+
+ if (mwifiex_read_data_sync(adapter, card->mp_regs,
+ card->reg->max_mp_regs,
+ REG_PORT | MWIFIEX_SDIO_BYTE_MODE_MASK, 0)) {
+ dev_err(adapter->dev, "read mp_regs failed\n");
+ return;
+ }
+
+ sdio_ireg = card->mp_regs[HOST_INTSTATUS_REG];
+ if (sdio_ireg) {
+ /*
+ * DN_LD_HOST_INT_STATUS and/or UP_LD_HOST_INT_STATUS
+ * For SDIO new mode CMD port interrupts
+ * DN_LD_CMD_PORT_HOST_INT_STATUS and/or
+ * UP_LD_CMD_PORT_HOST_INT_STATUS
+ * Clear the interrupt status register
+ */
+ dev_dbg(adapter->dev, "int: sdio_ireg = %#x\n", sdio_ireg);
+ spin_lock_irqsave(&adapter->int_lock, flags);
+ adapter->int_status |= sdio_ireg;
+ spin_unlock_irqrestore(&adapter->int_lock, flags);
+ }
+}
+
+/*
+ * SDIO interrupt handler.
+ *
+ * This function reads the interrupt status from firmware and handles
+ * the interrupt in current thread (ksdioirqd) right away.
+ */
+static void
+mwifiex_sdio_interrupt(struct sdio_func *func)
+{
+ struct mwifiex_adapter *adapter;
+ struct sdio_mmc_card *card;
+
+ card = sdio_get_drvdata(func);
+ if (!card || !card->adapter) {
+ pr_debug("int: func=%p card=%p adapter=%p\n",
+ func, card, card ? card->adapter : NULL);
+ return;
+ }
+ adapter = card->adapter;
+
+ if (!adapter->pps_uapsd_mode && adapter->ps_state == PS_STATE_SLEEP)
+ adapter->ps_state = PS_STATE_AWAKE;
+
+ mwifiex_interrupt_status(adapter);
+ mwifiex_main_process(adapter);
+}
+
+/*
* This function enables the host interrupt.
*
* The host interrupt enable mask is written to the card
@@ -963,65 +1019,6 @@ static int mwifiex_check_fw_status(struct mwifiex_adapter *adapter,
}
/*
- * This function reads the interrupt status from card.
- */
-static void mwifiex_interrupt_status(struct mwifiex_adapter *adapter)
-{
- struct sdio_mmc_card *card = adapter->card;
- u8 sdio_ireg;
- unsigned long flags;
-
- if (mwifiex_read_data_sync(adapter, card->mp_regs,
- card->reg->max_mp_regs,
- REG_PORT | MWIFIEX_SDIO_BYTE_MODE_MASK, 0)) {
- dev_err(adapter->dev, "read mp_regs failed\n");
- return;
- }
-
- sdio_ireg = card->mp_regs[HOST_INTSTATUS_REG];
- if (sdio_ireg) {
- /*
- * DN_LD_HOST_INT_STATUS and/or UP_LD_HOST_INT_STATUS
- * For SDIO new mode CMD port interrupts
- * DN_LD_CMD_PORT_HOST_INT_STATUS and/or
- * UP_LD_CMD_PORT_HOST_INT_STATUS
- * Clear the interrupt status register
- */
- dev_dbg(adapter->dev, "int: sdio_ireg = %#x\n", sdio_ireg);
- spin_lock_irqsave(&adapter->int_lock, flags);
- adapter->int_status |= sdio_ireg;
- spin_unlock_irqrestore(&adapter->int_lock, flags);
- }
-}
-
-/*
- * SDIO interrupt handler.
- *
- * This function reads the interrupt status from firmware and handles
- * the interrupt in current thread (ksdioirqd) right away.
- */
-static void
-mwifiex_sdio_interrupt(struct sdio_func *func)
-{
- struct mwifiex_adapter *adapter;
- struct sdio_mmc_card *card;
-
- card = sdio_get_drvdata(func);
- if (!card || !card->adapter) {
- pr_debug("int: func=%p card=%p adapter=%p\n",
- func, card, card ? card->adapter : NULL);
- return;
- }
- adapter = card->adapter;
-
- if (!adapter->pps_uapsd_mode && adapter->ps_state == PS_STATE_SLEEP)
- adapter->ps_state = PS_STATE_AWAKE;
-
- mwifiex_interrupt_status(adapter);
- mwifiex_main_process(adapter);
-}
-
-/*
* This function decodes a received packet.
*
* Based on the type, the packet is treated as either a data, or
--
1.8.2.3
^ permalink raw reply related
* [PATCH 16/21] mwifiex: replace mdelay with msleep
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Amitkumar Karwar <akarwar@marvell.com>
It is observed that when wrong firmware is downloaded for
PCIe card, system hangs for 10 seconds. The reason is mdelay()
is used when firmware status is polled.
Replace mdelay with msleep(non-blocking API) to fix the issue.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/pcie.c | 2 +-
drivers/net/wireless/mwifiex/sdio.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
index dce6486..098153f 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -1942,7 +1942,7 @@ mwifiex_check_fw_status(struct mwifiex_adapter *adapter, u32 poll_num)
ret = 0;
break;
} else {
- mdelay(100);
+ msleep(100);
ret = -1;
}
}
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index 5ef49f2..c32a735 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -944,7 +944,7 @@ static int mwifiex_check_fw_status(struct mwifiex_adapter *adapter,
ret = 0;
break;
} else {
- mdelay(100);
+ msleep(100);
ret = -1;
}
}
--
1.8.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox