Signed-off-by: Vivek Natarajan <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_hw.c b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
index 6fa3c24..7f5de6e 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
@@ -78,15 +78,15 @@ static void ar9003_hw_init_mode_regs(struct ath_hw *ah)
/* Awake Setting */
INIT_INI_ARRAY(&ah->iniPcieSerdes,
- ar9485_1_1_pcie_phy_pll_on_clkreq_disable_L1,
- ARRAY_SIZE(ar9485_1_1_pcie_phy_pll_on_clkreq_disable_L1),
+ ar9485_1_1_pcie_phy_clkreq_disable_L1,
+ ARRAY_SIZE(ar9485_1_1_pcie_phy_clkreq_disable_L1),
2);
/* Sleep Setting */
INIT_INI_ARRAY(&ah->iniPcieSerdesLowPower,
- ar9485_1_1_pcie_phy_pll_on_clkreq_disable_L1,
- ARRAY_SIZE(ar9485_1_1_pcie_phy_pll_on_clkreq_disable_L1),
+ ar9485_1_1_pcie_phy_clkreq_disable_L1,
+ ARRAY_SIZE(ar9485_1_1_pcie_phy_clkreq_disable_L1),
2);
} else if (AR_SREV_9485(ah)) {
/* mac */
--
1.6.3.3
Initialize txq to avoid this warning:
drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_flush’:
drivers/net/wireless/ath/ath9k/main.c:2138: warning: ‘txq’ may be used uninitialized in this function
Signed-off-by: Vivek Natarajan <[email protected]>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 9b03b5a..238fb76 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2135,7 +2135,7 @@ static void ath9k_flush(struct ieee80211_hw *hw, bool drop)
{
#define ATH_FLUSH_TIMEOUT 60 /* ms */
struct ath_softc *sc = hw->priv;
- struct ath_txq *txq;
+ struct ath_txq *txq = NULL;
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
int i, j, npend = 0;
--
1.6.3.3
pll_work should be cancelled on full_sleep or it may cause
redundant chip reset.
Signed-off-by: Vivek Natarajan <[email protected]>
---
drivers/net/wireless/ath/ath9k/main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index a715500..9b03b5a 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -910,6 +910,8 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
ath9k_hw_set_gpio(ah, ah->led_pin, 0);
ieee80211_wake_queues(hw);
+ ieee80211_queue_delayed_work(hw, &sc->hw_pll_work, HZ/2);
+
out:
spin_unlock_bh(&sc->sc_pcu_lock);
@@ -923,6 +925,8 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
int r;
ath9k_ps_wakeup(sc);
+ cancel_delayed_work_sync(&sc->hw_pll_work);
+
spin_lock_bh(&sc->sc_pcu_lock);
ieee80211_stop_queues(hw);
--
1.6.3.3
On Fri, Feb 25, 2011 at 05:31:03PM +0530, Vivek Natarajan wrote:
> Initialize txq to avoid this warning:
>
> drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_flush’:
> drivers/net/wireless/ath/ath9k/main.c:2138: warning: ‘txq’ may be used uninitialized in this function
thanks, my gcc (4.4.3) does not complain this :).
>
> Signed-off-by: Vivek Natarajan <[email protected]>
> ---
> drivers/net/wireless/ath/ath9k/main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index 9b03b5a..238fb76 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -2135,7 +2135,7 @@ static void ath9k_flush(struct ieee80211_hw *hw, bool drop)
> {
> #define ATH_FLUSH_TIMEOUT 60 /* ms */
> struct ath_softc *sc = hw->priv;
> - struct ath_txq *txq;
> + struct ath_txq *txq = NULL;
> struct ath_hw *ah = sc->sc_ah;
> struct ath_common *common = ath9k_hw_common(ah);
> int i, j, npend = 0;
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 25, 2011 at 4:01 AM, Vivek Natarajan <[email protected]> wrote:
> Signed-off-by: Vivek Natarajan <[email protected]>
Was this a stable fix? If not why not?
Luis
On Wed, Mar 16, 2011 at 5:04 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Fri, Feb 25, 2011 at 4:01 AM, Vivek Natarajan <[email protected]> wrote:
>> Signed-off-by: Vivek Natarajan <[email protected]>
>
> Was this a stable fix? If not why not?
This certainly smells like a stable fix, this seems similar to this other fix:
commit 58c5296991d233f2e492aa7a884635bba478cf12
Author: Luis R. Rodriguez <[email protected]>
Date: Thu Jan 13 18:19:29 2011 -0800
ath9k_hw: ASPM interoperability fix for AR9380/AR9382
There is an interoperability with AR9382/AR9380 in L1 state with a
few root complexes which can cause a hang. This is fixed by
setting some work around bits on the PCIE PHY. We fix by using
a new ini array to modify these bits when the radio is idle.
Cc: [email protected]
Cc: Jack Lee <[email protected]>
Cc: Carl Huang <[email protected]>
Cc: David Quan <[email protected]>
Cc: Nael Atallah <[email protected]>
Cc: Sarvesh Shrivastava <[email protected]>
Signed-off-by: Luis R. Rodriguez <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Without this patch I believe we will get AR9485 hanging in L1 state
with some root complexes. Can someone confirm?
Vivek, in the future can you please elaborate a little more on the
commit log entries and if its a "fix" of some sort elaborate on the
impact of not applying th patch.
Thanks,
Luis
On Thu, Mar 17, 2011 at 11:38 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Wed, Mar 16, 2011 at 5:04 PM, Luis R. Rodriguez <[email protected]> wrote:
>> On Fri, Feb 25, 2011 at 4:01 AM, Vivek Natarajan <[email protected]> wrote:
>>> Signed-off-by: Vivek Natarajan <[email protected]>
>>
>> Was this a stable fix? If not why not?
>
> This certainly smells like a stable fix
OK so AR9485 1.1 support did not make it into 2.6.38, and this fix is
applicable only to AR9485 1.1 so the patch in question is not
applicable to stable. The 2.6.38 release however does have AR9485 1.0
support. Will we have any devices in the field with AR9485 1.0 ? Did
that revision not require a similar fix? On 2.6.38 and on linux-next I
see we have for 1.0:
/* Awake Setting */
INIT_INI_ARRAY(&ah->iniPcieSerdes,
ar9485_1_0_pcie_phy_pll_on_clkreq_disable_L1,
ARRAY_SIZE(ar9485_1_0_pcie_phy_pll_on_clkreq_disable_L1),
2);
/* Sleep Setting */
INIT_INI_ARRAY(&ah->iniPcieSerdesLowPower,
ar9485_1_0_pcie_phy_pll_on_clkreq_enable_L1,
ARRAY_SIZE(ar9485_1_0_pcie_phy_pll_on_clkreq_enable_L1),
2);
Luis
On Fri, Mar 18, 2011 at 12:16 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Thu, Mar 17, 2011 at 11:38 AM, Luis R. Rodriguez <[email protected]> wrote:
>> On Wed, Mar 16, 2011 at 5:04 PM, Luis R. Rodriguez <[email protected]> wrote:
>>> On Fri, Feb 25, 2011 at 4:01 AM, Vivek Natarajan <[email protected]> wrote:
>>>> Signed-off-by: Vivek Natarajan <[email protected]>
>>>
>>> Was this a stable fix? If not why not?
>>
>> This certainly smells like a stable fix
>
> OK so AR9485 1.1 support did not make it into 2.6.38, and this fix is
> applicable only to AR9485 1.1 so the patch in question is not
> applicable to stable. The 2.6.38 release however does have AR9485 1.0
> support. Will we have any devices in the field with AR9485 1.0 ? Did
> that revision not require a similar fix? On 2.6.38 and on linux-next I
> see we have for 1.0:
>
> ? ? ? ? ? ? ? ?/* Awake Setting */
>
> ? ? ? ? ? ? ? ?INIT_INI_ARRAY(&ah->iniPcieSerdes,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ar9485_1_0_pcie_phy_pll_on_clkreq_disable_L1,
>
> ARRAY_SIZE(ar9485_1_0_pcie_phy_pll_on_clkreq_disable_L1),
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?2);
>
> ? ? ? ? ? ? ? ?/* Sleep Setting */
>
> ? ? ? ? ? ? ? ?INIT_INI_ARRAY(&ah->iniPcieSerdesLowPower,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ar9485_1_0_pcie_phy_pll_on_clkreq_enable_L1,
>
> ARRAY_SIZE(ar9485_1_0_pcie_phy_pll_on_clkreq_enable_L1),
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?2);
We did not notice any issue with the older code atleast from my
testing. There was an error in porting the internal codebase for
AR9485 1.0 which is fixed by the above patch.
Thanks
Vivek.