* [PATCH 10/11] ath9k: Set SWCOM value for CUS198
From: Sujith Manoharan @ 2013-08-04 8:52 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1375606322-9983-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
CUS198/CUS230 cards require a custom value to be
programmed into the SWCOM register. Assign this during
init time.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/init.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 9dc6773..38f461c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -312,6 +312,7 @@ struct ath9k_ops_config {
/* Platform specific config */
u32 xlna_gpio;
+ u32 ant_ctrl_comm2g_switch_enable;
bool xatten_margin_cfg;
};
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index b678add..4afe30e 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -526,6 +526,7 @@ static void ath9k_init_platform(struct ath_softc *sc)
ATH9K_PCI_CUS230)) {
ah->config.xlna_gpio = 9;
ah->config.xatten_margin_cfg = true;
+ ah->config.ant_ctrl_comm2g_switch_enable = 0x000BBB88;
sc->ant_comb.low_rssi_thresh = 20;
sc->ant_comb.fast_div_bias = 3;
--
1.8.3.4
^ permalink raw reply related
* [PATCH 11/11] ath9k: Support ANT diversity for WB225
From: Sujith Manoharan @ 2013-08-04 8:52 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1375606322-9983-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
WB225 based cards like CUS198 and CUS230 support
both fast antenna diversity and LNA combining. Add support
for this and also program the SWCOM register with the
correct "ant_ctrl_comm2g_switch_enable" value.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 5 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 2 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 120 +++++++++++++++++--------
3 files changed, 86 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index c2f1f18..178052f 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3541,13 +3541,12 @@ static u16 ar9003_switch_com_spdt_get(struct ath_hw *ah, bool is2ghz)
return le16_to_cpu(ar9003_modal_header(ah, is2ghz)->switchcomspdt);
}
-
-static u32 ar9003_hw_ant_ctrl_common_get(struct ath_hw *ah, bool is2ghz)
+u32 ar9003_hw_ant_ctrl_common_get(struct ath_hw *ah, bool is2ghz)
{
return le32_to_cpu(ar9003_modal_header(ah, is2ghz)->antCtrlCommon);
}
-static u32 ar9003_hw_ant_ctrl_common_2_get(struct ath_hw *ah, bool is2ghz)
+u32 ar9003_hw_ant_ctrl_common_2_get(struct ath_hw *ah, bool is2ghz)
{
return le32_to_cpu(ar9003_modal_header(ah, is2ghz)->antCtrlCommon2);
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
index 874f657..75d4fb4 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -334,6 +334,8 @@ struct ar9300_eeprom {
s32 ar9003_hw_get_tx_gain_idx(struct ath_hw *ah);
s32 ar9003_hw_get_rx_gain_idx(struct ath_hw *ah);
+u32 ar9003_hw_ant_ctrl_common_get(struct ath_hw *ah, bool is2ghz);
+u32 ar9003_hw_ant_ctrl_common_2_get(struct ath_hw *ah, bool is2ghz);
u8 *ar9003_get_spur_chan_ptr(struct ath_hw *ah, bool is_2ghz);
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 55021f1..4898829 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1414,58 +1414,102 @@ static void ar9003_hw_antdiv_comb_conf_set(struct ath_hw *ah,
static void ar9003_hw_set_bt_ant_diversity(struct ath_hw *ah, bool enable)
{
+ struct ath9k_hw_capabilities *pCap = &ah->caps;
u8 ant_div_ctl1;
u32 regval;
- if (!AR_SREV_9565(ah))
+ if (!AR_SREV_9485(ah) && !AR_SREV_9565(ah))
return;
+ if (AR_SREV_9485(ah)) {
+ regval = ar9003_hw_ant_ctrl_common_2_get(ah,
+ IS_CHAN_2GHZ(ah->curchan));
+ if (enable) {
+ regval &= ~AR_SWITCH_TABLE_COM2_ALL;
+ regval |= ah->config.ant_ctrl_comm2g_switch_enable;
+ }
+ REG_RMW_FIELD(ah, AR_PHY_SWITCH_COM_2,
+ AR_SWITCH_TABLE_COM2_ALL, regval);
+ }
+
ant_div_ctl1 = ah->eep_ops->get_eeprom(ah, EEP_ANT_DIV_CTL1);
+ /*
+ * Set MAIN/ALT LNA conf.
+ * Set MAIN/ALT gain_tb.
+ */
regval = REG_READ(ah, AR_PHY_MC_GAIN_CTRL);
regval &= (~AR_ANT_DIV_CTRL_ALL);
regval |= (ant_div_ctl1 & 0x3f) << AR_ANT_DIV_CTRL_ALL_S;
- regval &= ~AR_PHY_ANT_DIV_LNADIV;
- regval |= ((ant_div_ctl1 >> 6) & 0x1) << AR_PHY_ANT_DIV_LNADIV_S;
-
- if (enable)
- regval |= AR_ANT_DIV_ENABLE;
-
REG_WRITE(ah, AR_PHY_MC_GAIN_CTRL, regval);
- regval = REG_READ(ah, AR_PHY_CCK_DETECT);
- regval &= ~AR_FAST_DIV_ENABLE;
- regval |= ((ant_div_ctl1 >> 7) & 0x1) << AR_FAST_DIV_ENABLE_S;
-
- if (enable)
- regval |= AR_FAST_DIV_ENABLE;
-
- REG_WRITE(ah, AR_PHY_CCK_DETECT, regval);
-
- if (enable) {
- REG_SET_BIT(ah, AR_PHY_MC_GAIN_CTRL,
- (1 << AR_PHY_ANT_SW_RX_PROT_S));
- if (ah->curchan && IS_CHAN_2GHZ(ah->curchan))
- REG_SET_BIT(ah, AR_PHY_RESTART,
- AR_PHY_RESTART_ENABLE_DIV_M2FLAG);
- REG_SET_BIT(ah, AR_BTCOEX_WL_LNADIV,
- AR_BTCOEX_WL_LNADIV_FORCE_ON);
- } else {
- REG_CLR_BIT(ah, AR_PHY_MC_GAIN_CTRL, AR_ANT_DIV_ENABLE);
- REG_CLR_BIT(ah, AR_PHY_MC_GAIN_CTRL,
- (1 << AR_PHY_ANT_SW_RX_PROT_S));
- REG_CLR_BIT(ah, AR_PHY_CCK_DETECT, AR_FAST_DIV_ENABLE);
- REG_CLR_BIT(ah, AR_BTCOEX_WL_LNADIV,
- AR_BTCOEX_WL_LNADIV_FORCE_ON);
-
+ if (AR_SREV_9485_11(ah)) {
+ /*
+ * Enable LNA diversity.
+ */
regval = REG_READ(ah, AR_PHY_MC_GAIN_CTRL);
- regval &= ~(AR_PHY_ANT_DIV_MAIN_LNACONF |
- AR_PHY_ANT_DIV_ALT_LNACONF |
- AR_PHY_ANT_DIV_MAIN_GAINTB |
- AR_PHY_ANT_DIV_ALT_GAINTB);
- 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);
+ regval &= ~AR_PHY_ANT_DIV_LNADIV;
+ regval |= ((ant_div_ctl1 >> 6) & 0x1) << AR_PHY_ANT_DIV_LNADIV_S;
+ if (enable)
+ regval |= AR_ANT_DIV_ENABLE;
+
REG_WRITE(ah, AR_PHY_MC_GAIN_CTRL, regval);
+
+ /*
+ * Enable fast antenna diversity.
+ */
+ regval = REG_READ(ah, AR_PHY_CCK_DETECT);
+ regval &= ~AR_FAST_DIV_ENABLE;
+ regval |= ((ant_div_ctl1 >> 7) & 0x1) << AR_FAST_DIV_ENABLE_S;
+ if (enable)
+ regval |= AR_FAST_DIV_ENABLE;
+
+ REG_WRITE(ah, AR_PHY_CCK_DETECT, regval);
+
+ if (pCap->hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
+ regval = REG_READ(ah, AR_PHY_MC_GAIN_CTRL);
+ regval &= (~(AR_PHY_ANT_DIV_MAIN_LNACONF |
+ AR_PHY_ANT_DIV_ALT_LNACONF |
+ AR_PHY_ANT_DIV_ALT_GAINTB |
+ AR_PHY_ANT_DIV_MAIN_GAINTB));
+ /*
+ * Set MAIN to LNA1 and ALT to LNA2 at the
+ * beginning.
+ */
+ 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);
+ }
+ } else if (AR_SREV_9565(ah)) {
+ if (enable) {
+ REG_SET_BIT(ah, AR_PHY_MC_GAIN_CTRL,
+ (1 << AR_PHY_ANT_SW_RX_PROT_S));
+ if (ah->curchan && IS_CHAN_2GHZ(ah->curchan))
+ REG_SET_BIT(ah, AR_PHY_RESTART,
+ AR_PHY_RESTART_ENABLE_DIV_M2FLAG);
+ REG_SET_BIT(ah, AR_BTCOEX_WL_LNADIV,
+ AR_BTCOEX_WL_LNADIV_FORCE_ON);
+ } else {
+ REG_CLR_BIT(ah, AR_PHY_MC_GAIN_CTRL, AR_ANT_DIV_ENABLE);
+ REG_CLR_BIT(ah, AR_PHY_MC_GAIN_CTRL,
+ (1 << AR_PHY_ANT_SW_RX_PROT_S));
+ REG_CLR_BIT(ah, AR_PHY_CCK_DETECT, AR_FAST_DIV_ENABLE);
+ REG_CLR_BIT(ah, AR_BTCOEX_WL_LNADIV,
+ AR_BTCOEX_WL_LNADIV_FORCE_ON);
+
+ regval = REG_READ(ah, AR_PHY_MC_GAIN_CTRL);
+ regval &= ~(AR_PHY_ANT_DIV_MAIN_LNACONF |
+ AR_PHY_ANT_DIV_ALT_LNACONF |
+ AR_PHY_ANT_DIV_MAIN_GAINTB |
+ AR_PHY_ANT_DIV_ALT_GAINTB);
+ 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);
+ }
}
}
--
1.8.3.4
^ permalink raw reply related
* Re: Power saving features for iwl4965
From: Pedro Francisco @ 2013-08-04 14:24 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <20130731120848.GA31732@redhat.com>
On Wed, Jul 31, 2013 at 1:08 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Jul 17, 2013 at 12:48:30PM +0100, Pedro Francisco wrote:
>> On Tue, Jul 16, 2013 at 11:27 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> >> I seem only to be able to trigger it with disable_hw_scan=0, I need
>> >> further testing with disable_hw_scan=1 (I use disable_hw_scan=0
>> >> because it prevents me from getting disconnected from eduroam Cisco
>> >> APs -- haven't tested disable_hw_scan=0 since the VOIP-friendly SW
>> >> scanning patch, however).
>> >>
>> >> Do you want the log anyway? (modprobe iwl3945 debug=0x47ffffff
>> >> disable_hw_scan=0 and runtime PCI powersave also enabled -- I don't
>> >> know if it matters).
>> >
>> > As this is not causing troubles with default disable_hw_scan option,
>> > I'll post that patch.
>>
>> My mistake, I can trigger error conditions _independently_ of
>> disable_hw_scan option being enabled or disabled, as long as powersave
>> is enabled.
>>
>> I'll send you a private email with the logs.
>
> I think I found bug which couse this firmware crash. We have only 5
> queues so updating write_ptr for txq[5] can cause random value write
> to HBUS_TARG_WRPTR register. I also added spin_lock to do not abuse
> writes we do in tx skb.
>
> Please test attached patch (with powersave on :-)
Still not working :( I tested for two nights, first one was fine,
second was not (the only difference was I had kernel parameter
`slub_debug` on the second night, but my guess it shouldn't affect
anything?).
Snippet of log follows, full logs I'll send privately (beware,
unzipped it's 423MB).
Anyway, any idea what is the value 0xa5a5a5a2 ? It's always the same
value which makes the reloaded firmware to fail... And in other
firmware failures around the Web, both iwlegacy and iwlwifi.
Aug 4 09:23:58 s2 kernel: [32309.937084] iwl3945 0000:02:00.0: Queue
4 stuck for 2004 ms.
Aug 4 09:23:58 s2 kernel: [32309.937106] iwl3945 0000:02:00.0: On
demand firmware reload
Aug 4 09:23:58 s2 kernel: [32309.937128] ieee80211 phy1: U
__il3945_down iwl3945 is going down
Aug 4 09:23:58 s2 kernel: [32309.937137] ieee80211 phy1: U
il_scan_cancel_timeout Scan cancel timeout
Aug 4 09:23:58 s2 kernel: [32309.937143] ieee80211 phy1: U
il_do_scan_abort Not performing scan to abort
Aug 4 09:23:58 s2 kernel: [32309.937149] ieee80211 phy1: U
il_clear_ucode_stations Clearing ucode stations in driver
Aug 4 09:23:58 s2 kernel: [32309.937155] ieee80211 phy1: U
il_clear_ucode_stations Clearing ucode active for station 0
Aug 4 09:23:58 s2 kernel: [32309.937162] ieee80211 phy1: U
il_clear_ucode_stations Clearing ucode active for station 24
Aug 4 09:23:58 s2 kernel: [32309.938116] ieee80211 phy1: U
_il_apm_stop Stop card, put in low power state
Aug 4 09:23:58 s2 kernel: [32309.938116] iwl3945 0000:02:00.0: Master
Disable Timed Out, 100 usec
Aug 4 09:23:58 s2 kernel: [32309.938116] ieee80211 phy1: U
_il_apm_stop_master stop master
Aug 4 09:23:58 s2 kernel: [32309.954705] ieee80211 phy1: U
il3945_clear_free_frames 0 frames on pre-allocated heap on clear.
Aug 4 09:23:58 s2 kernel: [32309.954740] ieee80211 phy1: Hardware
restart was requested
Aug 4 09:23:58 s2 kernel: [32309.954757] ieee80211 phy1: U
il3945_mac_start enter
Aug 4 09:23:58 s2 kernel: [32309.954763] ieee80211 phy1: U
il_prep_station Add STA to driver ID 24: ff:ff:ff:ff:ff:ff
Aug 4 09:23:58 s2 kernel: [32309.954774] ieee80211 phy1: U
il_apm_init Init card's basic functions
Aug 4 09:23:58 s2 kernel: [32309.955111] ieee80211 phy1: U
il3945_nic_config HW Revision ID = 0x2
Aug 4 09:23:58 s2 kernel: [32309.955117] ieee80211 phy1: U
il3945_nic_config 3945 RADIO-MM type
Aug 4 09:23:58 s2 kernel: [32309.955127] ieee80211 phy1: U
il3945_nic_config SKU OP mode is basic
Aug 4 09:23:58 s2 kernel: [32309.955131] ieee80211 phy1: U
il3945_nic_config 3945ABG revision is 0xF1
Aug 4 09:23:58 s2 kernel: [32309.955140] ieee80211 phy1: U
il3945_nic_config Card M type B version is 0x3
Aug 4 09:23:58 s2 kernel: [32309.955150] ieee80211 phy1: U
il3945_nic_config SW RF KILL supported in EEPROM.
Aug 4 09:23:58 s2 kernel: [32309.955153] ieee80211 phy1: U
il3945_nic_config HW RF KILL supported in EEPROM.
Aug 4 09:23:58 s2 kernel: [32309.974318] ieee80211 phy1: U
il3945_load_bsm Begin load bsm
Aug 4 09:23:58 s2 kernel: [32310.018857] ieee80211 phy1: U
il3945_verify_bsm Begin verify bsm
Aug 4 09:23:58 s2 kernel: [32310.020628] iwl3945 0000:02:00.0: BSM
uCode verification failed at addr 0x00003800+0 (of 900), is
0xa5a5a5a2, s/b 0xf802020
Aug 4 09:23:58 s2 kernel: [32310.020632] iwl3945 0000:02:00.0: Unable
to set up bootstrap uCode: -5
Aug 4 09:23:58 s2 kernel: [32310.020636] ieee80211 phy1: U
il3945_load_bsm Begin load bsm
Aug 4 09:23:58 s2 kernel: [32310.041691] hrtimer: interrupt took 3021833 ns
Aug 4 09:23:58 s2 kernel: [32310.065681] ieee80211 phy1: U
il3945_verify_bsm Begin verify bsm
Aug 4 09:23:58 s2 kernel: [32310.067345] iwl3945 0000:02:00.0: BSM
uCode verification failed at addr 0x00003800+0 (of 900), is
0xa5a5a5a2, s/b 0xf802020
--
Pedro
^ permalink raw reply
* Re: Power saving features for iwl4965
From: Pedro Francisco @ 2013-08-04 14:53 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <CAJZjf_zA+GyL9Wu3rKaNpU6Sn6_zO+Ng6T2S4Y=Y4rJjzA6RiQ@mail.gmail.com>
On Sun, Aug 4, 2013 at 3:24 PM, Pedro Francisco
<pedrogfrancisco@gmail.com> wrote:
> On Wed, Jul 31, 2013 at 1:08 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> On Wed, Jul 17, 2013 at 12:48:30PM +0100, Pedro Francisco wrote:
>>> On Tue, Jul 16, 2013 at 11:27 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>> >> I seem only to be able to trigger it with disable_hw_scan=0, I need
>>> >> further testing with disable_hw_scan=1 (I use disable_hw_scan=0
>>> >> because it prevents me from getting disconnected from eduroam Cisco
>>> >> APs -- haven't tested disable_hw_scan=0 since the VOIP-friendly SW
>>> >> scanning patch, however).
>>> >>
>>> >> Do you want the log anyway? (modprobe iwl3945 debug=0x47ffffff
>>> >> disable_hw_scan=0 and runtime PCI powersave also enabled -- I don't
>>> >> know if it matters).
>>> >
>>> > As this is not causing troubles with default disable_hw_scan option,
>>> > I'll post that patch.
>>>
>>> My mistake, I can trigger error conditions _independently_ of
>>> disable_hw_scan option being enabled or disabled, as long as powersave
>>> is enabled.
>>>
>>> I'll send you a private email with the logs.
>>
>> I think I found bug which couse this firmware crash. We have only 5
>> queues so updating write_ptr for txq[5] can cause random value write
>> to HBUS_TARG_WRPTR register. I also added spin_lock to do not abuse
>> writes we do in tx skb.
>>
>> Please test attached patch (with powersave on :-)
>
> Still not working :( I tested for two nights, first one was fine,
> second was not (the only difference was I had kernel parameter
> `slub_debug` on the second night, but my guess it shouldn't affect
> anything?).
>
> Snippet of log follows, full logs I'll send privately (beware,
> unzipped it's 423MB).
>
> Anyway, any idea what is the value 0xa5a5a5a2 ? It's always the same
> value which makes the reloaded firmware to fail... And in other
> firmware failures around the Web, both iwlegacy and iwlwifi.
>
> Aug 4 09:23:58 s2 kernel: [32309.937084] iwl3945 0000:02:00.0: Queue
> 4 stuck for 2004 ms.
> Aug 4 09:23:58 s2 kernel: [32309.937106] iwl3945 0000:02:00.0: On
> demand firmware reload
> Aug 4 09:23:58 s2 kernel: [32309.937128] ieee80211 phy1: U
> __il3945_down iwl3945 is going down
> Aug 4 09:23:58 s2 kernel: [32309.937137] ieee80211 phy1: U
> il_scan_cancel_timeout Scan cancel timeout
> Aug 4 09:23:58 s2 kernel: [32309.937143] ieee80211 phy1: U
> il_do_scan_abort Not performing scan to abort
> Aug 4 09:23:58 s2 kernel: [32309.937149] ieee80211 phy1: U
> il_clear_ucode_stations Clearing ucode stations in driver
> Aug 4 09:23:58 s2 kernel: [32309.937155] ieee80211 phy1: U
> il_clear_ucode_stations Clearing ucode active for station 0
> Aug 4 09:23:58 s2 kernel: [32309.937162] ieee80211 phy1: U
> il_clear_ucode_stations Clearing ucode active for station 24
> Aug 4 09:23:58 s2 kernel: [32309.938116] ieee80211 phy1: U
> _il_apm_stop Stop card, put in low power state
> Aug 4 09:23:58 s2 kernel: [32309.938116] iwl3945 0000:02:00.0: Master
> Disable Timed Out, 100 usec
> Aug 4 09:23:58 s2 kernel: [32309.938116] ieee80211 phy1: U
> _il_apm_stop_master stop master
> Aug 4 09:23:58 s2 kernel: [32309.954705] ieee80211 phy1: U
> il3945_clear_free_frames 0 frames on pre-allocated heap on clear.
> Aug 4 09:23:58 s2 kernel: [32309.954740] ieee80211 phy1: Hardware
> restart was requested
> Aug 4 09:23:58 s2 kernel: [32309.954757] ieee80211 phy1: U
> il3945_mac_start enter
> Aug 4 09:23:58 s2 kernel: [32309.954763] ieee80211 phy1: U
> il_prep_station Add STA to driver ID 24: ff:ff:ff:ff:ff:ff
> Aug 4 09:23:58 s2 kernel: [32309.954774] ieee80211 phy1: U
> il_apm_init Init card's basic functions
> Aug 4 09:23:58 s2 kernel: [32309.955111] ieee80211 phy1: U
> il3945_nic_config HW Revision ID = 0x2
> Aug 4 09:23:58 s2 kernel: [32309.955117] ieee80211 phy1: U
> il3945_nic_config 3945 RADIO-MM type
> Aug 4 09:23:58 s2 kernel: [32309.955127] ieee80211 phy1: U
> il3945_nic_config SKU OP mode is basic
> Aug 4 09:23:58 s2 kernel: [32309.955131] ieee80211 phy1: U
> il3945_nic_config 3945ABG revision is 0xF1
> Aug 4 09:23:58 s2 kernel: [32309.955140] ieee80211 phy1: U
> il3945_nic_config Card M type B version is 0x3
> Aug 4 09:23:58 s2 kernel: [32309.955150] ieee80211 phy1: U
> il3945_nic_config SW RF KILL supported in EEPROM.
> Aug 4 09:23:58 s2 kernel: [32309.955153] ieee80211 phy1: U
> il3945_nic_config HW RF KILL supported in EEPROM.
> Aug 4 09:23:58 s2 kernel: [32309.974318] ieee80211 phy1: U
> il3945_load_bsm Begin load bsm
> Aug 4 09:23:58 s2 kernel: [32310.018857] ieee80211 phy1: U
> il3945_verify_bsm Begin verify bsm
> Aug 4 09:23:58 s2 kernel: [32310.020628] iwl3945 0000:02:00.0: BSM
> uCode verification failed at addr 0x00003800+0 (of 900), is
> 0xa5a5a5a2, s/b 0xf802020
> Aug 4 09:23:58 s2 kernel: [32310.020632] iwl3945 0000:02:00.0: Unable
> to set up bootstrap uCode: -5
> Aug 4 09:23:58 s2 kernel: [32310.020636] ieee80211 phy1: U
> il3945_load_bsm Begin load bsm
> Aug 4 09:23:58 s2 kernel: [32310.041691] hrtimer: interrupt took 3021833 ns
> Aug 4 09:23:58 s2 kernel: [32310.065681] ieee80211 phy1: U
> il3945_verify_bsm Begin verify bsm
> Aug 4 09:23:58 s2 kernel: [32310.067345] iwl3945 0000:02:00.0: BSM
> uCode verification failed at addr 0x00003800+0 (of 900), is
> 0xa5a5a5a2, s/b 0xf802020
Other thing, which may or may not be relevant. The 'script':
rmmod iwl3945; modprobe iwl3945 debug=0x47ffffff ; sleep 10; rmmod
iwl3945; modprobe iwl3945
At the end of this 'script', shouldn't debug mode be disabled? I
thought it would be disabled, but until `modprobe iwl3945 debug=0` is
done, debug is still active. Does this mean firmware reload/module
reload isn't completely resetting the card, as I suppose it was
supposed to do?
--
Pedro
^ permalink raw reply
* [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Alexey Khoroshilov @ 2013-08-05 3:02 UTC (permalink / raw)
To: Jouni Malinen, John W. Linville
Cc: Alexey Khoroshilov, linux-wireless, netdev, linux-kernel,
ldv-project, Alexey Khoroshilov
prism2_open() as an .ndo_open handler should not return positive numbers
in case of failure, but it does return 1 in a couple of places.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilorv@ispras.ru>
---
drivers/net/wireless/hostap/hostap_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 15f0fad..e4f56ad 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -667,7 +667,7 @@ static int prism2_open(struct net_device *dev)
if (local->no_pri) {
printk(KERN_DEBUG "%s: could not set interface UP - no PRI "
"f/w\n", dev->name);
- return 1;
+ return -ENODEV;
}
if ((local->func->card_present && !local->func->card_present(local)) ||
@@ -682,7 +682,7 @@ static int prism2_open(struct net_device *dev)
printk(KERN_WARNING "%s: could not enable MAC port\n",
dev->name);
prism2_close(dev);
- return 1;
+ return -ENODEV;
}
if (!local->dev_enabled)
prism2_callback(local, PRISM2_CALLBACK_ENABLE);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Alexey Khoroshilov @ 2013-08-05 3:18 UTC (permalink / raw)
To: Jouni Malinen, John W. Linville
Cc: linux-wireless, netdev, linux-kernel, ldv-project
In-Reply-To: <1375671750-2835-1-git-send-email-khoroshilov@ispras.ru>
Please ignore this mail, there is a misprint in signed-off line.
I will resend the patch.
On 08/05/2013 07:02 AM, Alexey Khoroshilov wrote:
> prism2_open() as an .ndo_open handler should not return positive numbers
> in case of failure, but it does return 1 in a couple of places.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilorv@ispras.ru>
> ---
> drivers/net/wireless/hostap/hostap_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
> index 15f0fad..e4f56ad 100644
> --- a/drivers/net/wireless/hostap/hostap_main.c
> +++ b/drivers/net/wireless/hostap/hostap_main.c
> @@ -667,7 +667,7 @@ static int prism2_open(struct net_device *dev)
> if (local->no_pri) {
> printk(KERN_DEBUG "%s: could not set interface UP - no PRI "
> "f/w\n", dev->name);
> - return 1;
> + return -ENODEV;
> }
>
> if ((local->func->card_present && !local->func->card_present(local)) ||
> @@ -682,7 +682,7 @@ static int prism2_open(struct net_device *dev)
> printk(KERN_WARNING "%s: could not enable MAC port\n",
> dev->name);
> prism2_close(dev);
> - return 1;
> + return -ENODEV;
> }
> if (!local->dev_enabled)
> prism2_callback(local, PRISM2_CALLBACK_ENABLE);
^ permalink raw reply
* [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Alexey Khoroshilov @ 2013-08-05 3:18 UTC (permalink / raw)
To: Jouni Malinen, John W. Linville
Cc: Alexey Khoroshilov, linux-wireless, netdev, linux-kernel,
ldv-project
prism2_open() as an .ndo_open handler should not return positive numbers
in case of failure, but it does return 1 in a couple of places.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/net/wireless/hostap/hostap_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 15f0fad..e4f56ad 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -667,7 +667,7 @@ static int prism2_open(struct net_device *dev)
if (local->no_pri) {
printk(KERN_DEBUG "%s: could not set interface UP - no PRI "
"f/w\n", dev->name);
- return 1;
+ return -ENODEV;
}
if ((local->func->card_present && !local->func->card_present(local)) ||
@@ -682,7 +682,7 @@ static int prism2_open(struct net_device *dev)
printk(KERN_WARNING "%s: could not enable MAC port\n",
dev->name);
prism2_close(dev);
- return 1;
+ return -ENODEV;
}
if (!local->dev_enabled)
prism2_callback(local, PRISM2_CALLBACK_ENABLE);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Joe Perches @ 2013-08-05 3:33 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Jouni Malinen, John W. Linville, linux-wireless, netdev,
linux-kernel, ldv-project
In-Reply-To: <1375672708-3017-1-git-send-email-khoroshilov@ispras.ru>
On Mon, 2013-08-05 at 07:18 +0400, Alexey Khoroshilov wrote:
> prism2_open() as an .ndo_open handler should not return positive numbers
> in case of failure, but it does return 1 in a couple of places.
>
> Found by Linux Driver Verification project (linuxtesting.org).
How?
http://linuxtesting.org/project/ldv
http://linuxtesting.org/results/ldv
Shows defects and patches to fix them, but not any script
used to find it.
^ permalink raw reply
* Re: [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Alexey Khoroshilov @ 2013-08-05 4:01 UTC (permalink / raw)
To: Joe Perches
Cc: Jouni Malinen, John W. Linville, linux-wireless, netdev,
linux-kernel, ldv-project
In-Reply-To: <1375673616.3133.23.camel@joe-AO722>
On 08/05/2013 07:33 AM, Joe Perches wrote:
> On Mon, 2013-08-05 at 07:18 +0400, Alexey Khoroshilov wrote:
>> prism2_open() as an .ndo_open handler should not return positive numbers
>> in case of failure, but it does return 1 in a couple of places.
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
> How?
>
> http://linuxtesting.org/project/ldv
> http://linuxtesting.org/results/ldv
>
> Shows defects and patches to fix them, but not any script
> used to find it.
There is a link to build instructions there:
http://forge.ispras.ru/projects/ldv/wiki/Downloading_and_Building_LDV
Currently it requires some efforts to install all the dependencies, the
simplest way is to use puppet script for Ubuntu 12.04 that you can find
in the repository.
--
Alexey
^ permalink raw reply
* [PATCH] ath6kl : Fix invalid pointer access on fuzz testing with AP mode
From: Mohammed Shafi Shajakhan @ 2013-08-05 4:49 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
In our Fuz testing, reference client corrupts the dest mac to "00:00:00:00:00:00"
in the WPA2 handshake no 2. During driver init the sta_list entries mac
addresses are by default "00:00:00:00:00:00". Driver returns an invalid
pointer (conn) and the drver shall crash, if rxtids (aggr_conn)
skb queues are accessed, since they would not be initialized.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/main.c b/drivers/net/wireless/ath/ath6kl/main.c
index d4fcfca..5839fc2 100644
--- a/drivers/net/wireless/ath/ath6kl/main.c
+++ b/drivers/net/wireless/ath/ath6kl/main.c
@@ -29,6 +29,9 @@ struct ath6kl_sta *ath6kl_find_sta(struct ath6kl_vif *vif, u8 *node_addr)
struct ath6kl_sta *conn = NULL;
u8 i, max_conn;
+ if (is_zero_ether_addr(node_addr))
+ return NULL;
+
max_conn = (vif->nw_type == AP_NETWORK) ? AP_MAX_NUM_STA : 0;
for (i = 0; i < max_conn; i++) {
--
1.7.9.5
^ permalink raw reply related
* Re: Ath6kl - Information required on FCC/R&TTE regulatory testing code
From: Kalle Valo @ 2013-08-05 5:28 UTC (permalink / raw)
To: narain vadivelu; +Cc: linux-wireless, ath6kl-devel, Hariharan Bojan
In-Reply-To: <CA+sSWSnSm6oEoqhX8AGCn8Y_8LvpYVO-4nadic_2_RcT3k+aNQ@mail.gmail.com>
narain vadivelu <narain.vel@gmail.com> writes:
> We want to know, does Ath6kl Linux driver supports or has "FCC/R&TTE
> regulatory" testing code?.
Please contact official QCA support for factory testing related
questions.
--
Kalle Valo
^ permalink raw reply
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Kalle Valo @ 2013-08-05 7:59 UTC (permalink / raw)
To: Arend van Spriel
Cc: Luis R. Rodriguez, linux-wireless, Ben Greear, Paul Stewart,
Felix Fietkau, Jouni Malinen
In-Reply-To: <51F8DA75.8040903@broadcom.com>
"Arend van Spriel" <arend@broadcom.com> writes:
> I am considering coming up with a new test framework for the brcm80211
> drivers using python scripting, which is why I started py80211
> experiment (available on github), but your mentioning of autotest
> makes me want to revisit that.
No no, please forget anything your heard about autotest and just focus
on py80211 ;)
More seriously, my experience with the autotest and any other test
frameworks are that they are so freaking huge and difficult to maintain
that eventually they just die. Small is beautiful and I have been
dreaming about a lean and mean python based nl80211 test harness for
drivers, but never found the time to do anything (my usual story). So
I'm eagerly waiting how your py80211 will workout.
--
Kalle Valo
^ permalink raw reply
* [PATCH 3/3] ath9k: Add more PCI IDs for WB225 cards
From: Sujith Manoharan @ 2013-08-05 9:38 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1375695508-1997-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/pci.c | 72 ++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 30652b4..76e8c35 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -72,6 +72,78 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
0xE075),
.driver_data = ATH9K_PCI_CUS230 | ATH9K_PCI_BT_ANT_DIV },
+ /* WB225 */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_ATHEROS,
+ 0x3119),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_ATHEROS,
+ 0x3122),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ 0x185F, /* WNC */
+ 0x3119),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ 0x185F, /* WNC */
+ 0x3027),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0x4105),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0x4106),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0x410D),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0x410E),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0x410F),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0xC706),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0xC680),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_SAMSUNG,
+ 0xC708),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_LENOVO,
+ 0x3218),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+ 0x0032,
+ PCI_VENDOR_ID_LENOVO,
+ 0x3219),
+ .driver_data = ATH9K_PCI_BT_ANT_DIV },
+
{ PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E AR9485 */
{ PCI_VDEVICE(ATHEROS, 0x0033) }, /* PCI-E AR9580 */
--
1.8.3.4
^ permalink raw reply related
* [PATCH 1/3] ath9k: Remove ath_ant_comb_update()
From: Sujith Manoharan @ 2013-08-05 9:38 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
During a HW reset, the diversity config is programmed
in the set_board_values() eeprom callback, there is no
need to do it again by calling ath_ant_comb_update().
Fixed antenna support is not fully handled for 1-stream
cards, it can be done later.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/antenna.c | 23 -----------------------
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 3 ---
4 files changed, 1 insertion(+), 28 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c
index 85391e6..dd1cc73 100644
--- a/drivers/net/wireless/ath/ath9k/antenna.c
+++ b/drivers/net/wireless/ath/ath9k/antenna.c
@@ -867,26 +867,3 @@ div_comb_done:
antcomb->main_recv_cnt = 0;
antcomb->alt_recv_cnt = 0;
}
-
-void ath_ant_comb_update(struct ath_softc *sc)
-{
- struct ath_hw *ah = sc->sc_ah;
- struct ath_common *common = ath9k_hw_common(ah);
- struct ath_hw_antcomb_conf div_ant_conf;
- u8 lna_conf;
-
- ath9k_hw_antdiv_comb_conf_get(ah, &div_ant_conf);
-
- if (sc->ant_rx == 1)
- lna_conf = ATH_ANT_DIV_COMB_LNA1;
- else
- lna_conf = ATH_ANT_DIV_COMB_LNA2;
-
- div_ant_conf.main_lna_conf = lna_conf;
- div_ant_conf.alt_lna_conf = lna_conf;
-
- ath9k_hw_antdiv_comb_conf_set(ah, &div_ant_conf);
-
- if (common->bt_ant_diversity)
- ath9k_hw_set_bt_ant_diversity(ah, true);
-}
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 18898ab..c497d52 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -628,7 +628,6 @@ struct ath_ant_comb {
};
void ath_ant_comb_scan(struct ath_softc *sc, struct ath_rx_status *rs);
-void ath_ant_comb_update(struct ath_softc *sc);
/********************/
/* Main driver core */
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index daa316b..a155190 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -307,7 +307,7 @@ static ssize_t write_file_bt_ant_diversity(struct file *file,
common->bt_ant_diversity = !!bt_ant_diversity;
ath9k_ps_wakeup(sc);
- ath_ant_comb_update(sc);
+ ath9k_hw_set_bt_ant_diversity(sc->sc_ah, common->bt_ant_diversity);
ath_dbg(common, CONFIG, "Enable WLAN/BT RX Antenna diversity: %d\n",
common->bt_ant_diversity);
ath9k_ps_restore(sc);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 1adb803..afeab3c 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -238,9 +238,6 @@ static bool ath_complete_reset(struct ath_softc *sc, bool start)
ath_restart_work(sc);
}
- if ((ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) && sc->ant_rx != 3)
- ath_ant_comb_update(sc);
-
ieee80211_wake_queues(sc->hw);
return true;
--
1.8.3.4
^ permalink raw reply related
* [PATCH 2/3] ath9k: Fix antenna control init for AR9485
From: Sujith Manoharan @ 2013-08-05 9:38 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1375695508-1997-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/ar9003_eeprom.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 178052f..abdc7ee 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3614,6 +3614,11 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
}
value = ar9003_hw_ant_ctrl_common_2_get(ah, is2ghz);
+ if (AR_SREV_9485(ah) && common->bt_ant_diversity) {
+ regval &= ~AR_SWITCH_TABLE_COM2_ALL;
+ regval |= ah->config.ant_ctrl_comm2g_switch_enable;
+
+ }
REG_RMW_FIELD(ah, AR_PHY_SWITCH_COM_2, AR_SWITCH_TABLE_COM2_ALL, value);
if ((AR_SREV_9462(ah)) && (ah->rxchainmask == 0x2)) {
@@ -3645,6 +3650,9 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
regval &= (~AR_PHY_ANT_DIV_LNADIV);
regval |= ((value >> 6) & 0x1) << AR_PHY_ANT_DIV_LNADIV_S;
+ if (AR_SREV_9485(ah) && common->bt_ant_diversity)
+ regval |= AR_ANT_DIV_ENABLE;
+
if (AR_SREV_9565(ah)) {
if (common->bt_ant_diversity) {
regval |= (1 << AR_PHY_ANT_SW_RX_PROT_S);
@@ -3656,10 +3664,14 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
REG_WRITE(ah, AR_PHY_MC_GAIN_CTRL, regval);
- /*enable fast_div */
+ /* enable fast_div */
regval = REG_READ(ah, AR_PHY_CCK_DETECT);
regval &= (~AR_FAST_DIV_ENABLE);
regval |= ((value >> 7) & 0x1) << AR_FAST_DIV_ENABLE_S;
+
+ if (AR_SREV_9485(ah) && common->bt_ant_diversity)
+ regval |= AR_FAST_DIV_ENABLE;
+
REG_WRITE(ah, AR_PHY_CCK_DETECT, regval);
if (pCap->hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
--
1.8.3.4
^ permalink raw reply related
* Re: pull-request: mac80211-next 2013-07-26
From: Simon Wunderlich @ 2013-08-05 10:01 UTC (permalink / raw)
To: John W. Linville; +Cc: Johannes Berg, linux-wireless, Mathias Kretschmer
In-Reply-To: <20130801192723.GD13922@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
Hey John,
since you have pulled the patches from Johannes, could you please also pick up
the ath9k/ath5k patches for the 5/10 MHz feature? Johannes included the nl/mac80211
parts of the patchset only, leaving the ath5k/ath9k parts unmerged.
It has been sent to this mailing list, the coverletter mail was:
> Subject: [PATCHv6 00/18] Add support for 5 and 10 MHz channels
> Date: Mon, 8 Jul 2013 16:55:48 +0200
> Message-Id: <1373295366-12823-1-git-send-email-siwu@hrz.tu-chemnitz.de>
It includes 5 ath9k and 3 ath5k patches.
If there are any troubles, I can repost of course.
Thanks,
Simon
On Thu, Aug 01, 2013 at 03:27:24PM -0400, John W. Linville wrote:
> On Fri, Jul 26, 2013 at 10:35:40AM +0200, Johannes Berg wrote:
> > John,
> >
> > This is a more traditional pull request without patches since they've
> > all been to the list :-) First set of updates for mac80211-next.
> >
> > The biggest change here is probably the initial 5/10 MHz support for
> > IBSS, the remaining patches are smaller features and some cleanups.
> >
> > Let me know if there's any problem.
> >
> > johannes
> >
> >
> > The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> >
> > Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git for-john
> >
> > for you to fetch changes up to c82b5a74cc739385db6e4275fe504a0e9469bf01:
> >
> > mac80211: make active monitor injection work w/ HW queue (2013-07-16 09:58:19 +0300)
>
> Pulling now...
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
From: Kay Sievers @ 2013-08-05 11:18 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek
Cc: Andy Lutomirski, systemd-devel, Linux Wireless List,
linux-hotplug, linux-kernel, Intel Linux Wireless, Johannes Berg
In-Reply-To: <20130802162850.GL32474@in.waw.pl>
On Fri, Aug 2, 2013 at 6:28 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek@in.waw.pl> wrote:
> On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote:
>> CONFIG_FW_LOADER_USER_HELPER=y
> Do you need this? Unsetting this should help.
>
> """This option enables / disables the invocation of user-helper
> (e.g. udev) for loading firmware files as a fallback after the
> direct file loading in kernel fails. The user-mode helper is
> no longer required unless you have a special firmware file that
> resides in a non-standard path."""
On recent systems, if the kernel configures
CONFIG_FW_LOADER_USER_HELPER=y and a firmware is not found by the
kernel, the kernel will issue a request which is ignored by userspace
and will block in that for 60 seconds.
Udev is no longer in the game of firmware loading, not even as a
fallback, it will just completely ignore all kernel firmware class
events.
The source code in udev to handle firmware requests is disabled by
default, currently still kept around for old kernels without the
in-kernel firmware loader, but it will be deleted in the near future.
Any issues with firmware timeouts should be addressed in the kernel by
disabling CONFIG_FW_LOADER_USER_HELPER or by removing the fallback
code from the in-kernel loader.
Kay
^ permalink raw reply
* Re: [[PATCHv2]rt2800usb: ampdu len] rt2800usb: update aggregation len
From: Helmut Schaa @ 2013-08-05 11:33 UTC (permalink / raw)
To: Sylvain ROGER RIEUNIER; +Cc: linux-wireless, rt2x00 Users List
In-Reply-To: <1375371582-31004-1-git-send-email-sylvain.roger.rieunier@gmail.com>
On Thu, Aug 1, 2013 at 5:39 PM, Sylvain ROGER RIEUNIER
<sylvain.roger.rieunier@gmail.com> wrote:
> From: Sylvain Roger Rieunier <sylvain.roger.rieunier@gmail.com>
>
> I tried to read periodically TX_AGG_CNT registers on the rt2800usb driver.
> I'had made USB synchronous and asynchronous read. But it's only reduces the
> bandwidth.
> Does anyone have an idea?
>
>
> Signed-off-by: Sylvain ROGER RIEUNIER <sylvain.roger.rieunier@gmail.com>
Instead of updating the statistics from within a timer can't you just
update them when reading the sysfs file?
Helmut
^ permalink raw reply
* Re: [PATCH v2] ath10k: add SoC power save option to PCI features map
From: Michal Kazior @ 2013-08-05 13:31 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1375430329-23352-1-git-send-email-bartosz.markowski@tieto.com>
On 2 August 2013 09:58, Bartosz Markowski <bartosz.markowski@tieto.com> wrote:
> Unify the PCI options location.
>
> By default the SoC PS option is disabled to boost the
> performance and due to poor stability on early HW revisions.
> In future we can remove the module parameter and turn on/off
> the PS for given hardware.
>
> This change also makes the pci module parameter for SoC PS static.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Hmm.. I'm worried about pci wake/sleep locking:
(a) pci_wake() (awake count =1)
(a) do something
Now, if pci_sleep() and pci_wake() happen simultaneously/are
preempted splitting primitive operations to:
(a) pci_sleep(): decrease awake count (=0)
(b) pci_wake(): increase awake count (=1), iowrite, wait for awake, return
(a) pci_sleep(): iowrite(). return
The flow in (b) now thinks the device is awake, but it's not
guaranteed to be anymore because it has been put to sleep by (a).
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: changing dev->needed_headroom/needed_tailroom?
From: Johannes Berg @ 2013-08-05 14:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Hutchings, netdev, linux-wireless
In-Reply-To: <1375449082.3927.5.camel@edumazet-glaptop>
On Fri, 2013-08-02 at 06:11 -0700, Eric Dumazet wrote:
> On Fri, 2013-08-02 at 10:55 +0200, Ben Hutchings wrote:
>
> > I don't think this is safe when the interface is running (even if
> > carrier is off). Some functions may read dev->needed_headroom twice and
> > rely on getting the same value each time.
>
> It should be no problem. Remaining unsafe places should be fixed.
Most interesting would be stack devs, which I hadn't even considered. In
any case, since I can't completely _rely_ on it, it's an optimisation,
the only bugs would be around the double-access and then running
over/under the SKB or so?
> We already had this discussion in the past, and some patches were
> issued. Check commit ae641949df01b85117845bec45328eab6d6fada1
> ("net: Remove all uses of LL_ALLOCATED_SPACE")
That would have addressed some of that, I guess.
I'm asking because some of the crypto stuff we do has fairly large
head/tailroom requirements and it seems I may need to add more. But if
you don't have crypto, it would be much smaller, so I figured we could
switch it.
johannes
^ permalink raw reply
* Re: [[PATCHv2]rt2800usb: ampdu len] rt2800usb: update aggregation len
From: Helmut Schaa @ 2013-08-05 15:35 UTC (permalink / raw)
To: Sylvain ROGER RIEUNIER; +Cc: linux-wireless, rt2x00 Users List
In-Reply-To: <CA+aCzhVEu63FWO6+Y=_jD1+UK=e3NKJSx1+oGb7V_aF4dBgxXg@mail.gmail.com>
Sylvain ROGER RIEUNIER <sylvain.roger.rieunier@gmail.com> schrieb:
>Dear Helmut,
>
>I already did a test using the Sysfs with an synchronous read. But more
>you
>read TX_AGG_CNT counters and more you reduce the bandwith.
>My idea was to make asynchronous read periodically to allow Sysfs
>reading without
>impact the bandwith performance.
>Do you have an other suggestion?
Maybe just rate limit register reading in the sysfs interface? Something like: we've just updated the stats a second ago, use the old data ...
Or as a different idea, schedule a work from the tx status path (the counters can only change if we transmit something), also rate limited ... This could be used for rt2800pci as well then ...
Helmut
>
>Sylvain
>
>
>
>2013/8/5 Helmut Schaa <helmut.schaa@googlemail.com>
>
>> On Thu, Aug 1, 2013 at 5:39 PM, Sylvain ROGER RIEUNIER
>> <sylvain.roger.rieunier@gmail.com> wrote:
>> > From: Sylvain Roger Rieunier <sylvain.roger.rieunier@gmail.com>
>> >
>> > I tried to read periodically TX_AGG_CNT registers on the rt2800usb
>> driver.
>> > I'had made USB synchronous and asynchronous read. But it's only
>reduces
>> the
>> > bandwidth.
>> > Does anyone have an idea?
>> >
>> >
>> > Signed-off-by: Sylvain ROGER RIEUNIER
><sylvain.roger.rieunier@gmail.com>
>>
>> Instead of updating the statistics from within a timer can't you just
>> update them when reading the sysfs file?
>> Helmut
>>
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
^ permalink raw reply
* Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
From: Andy Lutomirski @ 2013-08-05 16:09 UTC (permalink / raw)
To: Kay Sievers
Cc: Zbigniew Jędrzejewski-Szmek, systemd-devel,
Linux Wireless List, linux-hotplug, linux-kernel,
Intel Linux Wireless, Johannes Berg
In-Reply-To: <CAPXgP13_WRX-asL=MwCM9ERDDMq_7PLkXLr9hwTG-xCg7cm6_A@mail.gmail.com>
On Mon, Aug 5, 2013 at 4:18 AM, Kay Sievers <kay@vrfy.org> wrote:
> On Fri, Aug 2, 2013 at 6:28 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek@in.waw.pl> wrote:
>> On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote:
>>> CONFIG_FW_LOADER_USER_HELPER=y
>> Do you need this? Unsetting this should help.
>>
>> """This option enables / disables the invocation of user-helper
>> (e.g. udev) for loading firmware files as a fallback after the
>> direct file loading in kernel fails. The user-mode helper is
>> no longer required unless you have a special firmware file that
>> resides in a non-standard path."""
>
> On recent systems, if the kernel configures
> CONFIG_FW_LOADER_USER_HELPER=y and a firmware is not found by the
> kernel, the kernel will issue a request which is ignored by userspace
> and will block in that for 60 seconds.
>
> Udev is no longer in the game of firmware loading, not even as a
> fallback, it will just completely ignore all kernel firmware class
> events.
>
> The source code in udev to handle firmware requests is disabled by
> default, currently still kept around for old kernels without the
> in-kernel firmware loader, but it will be deleted in the near future.
Any chance you'd consider a less regression-inducing path to getting
rid of this feature? For example, have udev warn and immediate fail
firmware loading requests for a few releases, then just warn, then
drop support?
Meanwhile, CONFIG_FW_LOADER_USER_HELPER is still default y (!), so
udev has introduced massive bootup delays into the default
configuration with no warning. It might be nice to change it to
default n, get rid of everything that selects it, and possible even
rename it to something with LEGACY or OBSOLETE in the name so that
make oldconfig will prompt.
--Andy
>
> Any issues with firmware timeouts should be addressed in the kernel by
> disabling CONFIG_FW_LOADER_USER_HELPER or by removing the fallback
> code from the in-kernel loader.
>
> Kay
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [PATCH v2] ath10k: fix device teardown
From: Kalle Valo @ 2013-08-05 16:23 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1375427747-9539-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This fixes interrupt-related issue when no
> interfaces were running thus the device was
> considered powered down.
>
> The power_down() function isn't really powering
> down the device. It simply assumed it won't
> interrupt. This wasn't true in some cases and
> could lead to paging failures upon FW indication
> interrupt (i.e. FW crash) because some structures
> aren't allocated in that device state.
>
> One reason for that was that ar_pci->started
> wasn't reset. The other is interrupts should've
> been masked when teardown starts.
>
> The patch reorganized interrupt setup and makes
> sure ar_pci->started is reset accordingly.
>
> Reported-by: Ben Greear <greearb@candelatech.com>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
From: Andy Lutomirski @ 2013-08-05 16:29 UTC (permalink / raw)
To: linux-kernel, Kay Sievers
Cc: Zbigniew Jędrzejewski-Szmek, systemd-devel,
Linux Wireless List, linux-hotplug, Intel Linux Wireless,
Johannes Berg, Andy Lutomirski
In-Reply-To: <CALCETrXSnFPFVPkXHwz+FFA3=+pmz9V=cMHWwtN+jG1QJALWSQ@mail.gmail.com>
The systemd commit below can delay firmware loading by multiple
minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one
noticed that the systemd-udev change would break new kernels as well
as old kernels.
Since the kernel apparently can't count on reasonable userspace
support, turn this thing off by default.
commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a
Author: Tom Gundersen <teg@jklm.no>
Date: Mon Mar 18 15:12:18 2013 +0100
udev: make firmware loading optional and disable by default
Distros that whish to support old kernels should set
--with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware"
to retain the old behaviour.
---
drivers/base/Kconfig | 15 +++++++++++----
drivers/firmware/Kconfig | 1 -
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 5daa259..de3903e 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -146,13 +146,20 @@ config EXTRA_FIRMWARE_DIR
config FW_LOADER_USER_HELPER
bool "Fallback user-helper invocation for firmware loading"
depends on FW_LOADER
- default y
+ default n
help
This option enables / disables the invocation of user-helper
(e.g. udev) for loading firmware files as a fallback after the
- direct file loading in kernel fails. The user-mode helper is
- no longer required unless you have a special firmware file that
- resides in a non-standard path.
+ direct file loading in kernel fails.
+
+ Since March 2013, a default udev build does not understand
+ firmware loading requests. These udev versions will not
+ even indicate failure; instead they cause long timeouts.
+ This can dramatically slow down the boot process.
+
+ Say Y only if you have special firmware-loading requirements
+ and if you have a non-standard helper that will handle these
+ requests.
config DEBUG_DRIVER
bool "Driver Core verbose debug messages"
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 07478728..9387630 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -64,7 +64,6 @@ config DELL_RBU
tristate "BIOS update support for DELL systems via sysfs"
depends on X86
select FW_LOADER
- select FW_LOADER_USER_HELPER
help
Say m if you want to have the option of updating the BIOS for your
DELL system. Note you need a Dell OpenManage or Dell Update package (DUP)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] ath10k: add SoC power save option to PCI features map
From: Kalle Valo @ 2013-08-05 16:40 UTC (permalink / raw)
To: Michal Kazior; +Cc: Bartosz Markowski, linux-wireless, ath10k
In-Reply-To: <CA+BoTQkD5grL_5dJDgkwo40ET1zax56oN=ZGFxnyGqboQShbgQ@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 2 August 2013 09:58, Bartosz Markowski <bartosz.markowski@tieto.com> wrote:
>> Unify the PCI options location.
>>
>> By default the SoC PS option is disabled to boost the
>> performance and due to poor stability on early HW revisions.
>> In future we can remove the module parameter and turn on/off
>> the PS for given hardware.
>>
>> This change also makes the pci module parameter for SoC PS static.
>>
>> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
>
> Hmm.. I'm worried about pci wake/sleep locking:
>
> (a) pci_wake() (awake count =1)
> (a) do something
> Now, if pci_sleep() and pci_wake() happen simultaneously/are
> preempted splitting primitive operations to:
> (a) pci_sleep(): decrease awake count (=0)
> (b) pci_wake(): increase awake count (=1), iowrite, wait for awake, return
> (a) pci_sleep(): iowrite(). return
> The flow in (b) now thinks the device is awake, but it's not
> guaranteed to be anymore because it has been put to sleep by (a).
Yeah, there's a race alright. I wonder if I have ever seen a proper use
of a atomic variable in a wireless driver :)
But this doesn't prevent taking this patch as the race has existed since
the beginning, right?
--
Kalle Valo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox