Return-path: Received: from charlotte.tuxdriver.com ([70.61.120.58]:52833 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754614AbYJ2Xfq (ORCPT ); Wed, 29 Oct 2008 19:35:46 -0400 Date: Wed, 29 Oct 2008 19:34:26 -0400 From: "John W. Linville" To: Elias Oltmanns Cc: Nick Kossifidis , Bob Copeland , Jiri Slaby , "Luis R. Rodriguez" , linux-wireless@vger.kernel.org Subject: Re: [PATCH] ath5k: Fix reset sequence for AR5212 in general and RF5111 in particular Message-ID: <20081029233426.GF3485@tuxdriver.com> (sfid-20081030_003551_285465_53BA95C2) References: <87wsfvt76q.fsf@denkblock.local> <40f31dec0810261533g3143bd9bue0f3eff88c6936e9@mail.gmail.com> <87r663t1ds.fsf@denkblock.local> <40f31dec0810271331n7f374562x77da8ae55b9032db@mail.gmail.com> <873aifsfc9.fsf@denkblock.local> <40f31dec0810290749u2c065d17g5788eb22cf508142@mail.gmail.com> <87wsfrqw2t.fsf@denkblock.local> <40f31dec0810291051j605a281dg641d873bd0e3bbc1@mail.gmail.com> <87mygn2dd7.fsf@denkblock.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <87mygn2dd7.fsf@denkblock.local> Sender: linux-wireless-owner@vger.kernel.org List-ID: Well, I already merged v3...what is new here? On Thu, Oct 30, 2008 at 12:25:08AM +0100, Elias Oltmanns wrote: > "Nick Kossifidis" wrote: > > 2008/10/29 Bob Copeland : > >> On Wed, Oct 29, 2008 at 11:07 AM, Elias Oltmanns wrote: > > > >>>> > >>>> Patch looks OK, thanks a lot ;-) > >>>> > >>>> John can we get this get in stable until i update reset.c on wireless-testing ? > >>>> Would it be possible later to update mainline from wireless-testing ? > >>> > >>> Reading Documentation/stable_kernel_rules.txt, I very much doubt that > >>> this patch will go in unless we can at least point out something > >>> equivalent in mainline. So, we'll have to wait until your changes to > >>> reset.c have reached mainline, I'm afraid. > >> > >> Or, we could just send your patch to both stable and for 2.6.28. Then Nick > >> can fix up the difference or revert it in his rework. The rework is 2.6.29 > >> material, right? > >> > > > > ACK > > In that case, I'd suggest the following patch for 2.6.28-rc2. Once it > has been merged, I'll send the previous one off to the stable team. > > Regards, > > Elias > -------- > From: Elias Oltmanns > Subject: ath5k: Fix reset sequence for AR5212 in general and RF5111 in particular > > Take care to handle register 0xa228 exactly as in the HAL released by > Atheros. This change is required to make ath5k work again on my system > since commit 2203d6be (ath5k: Misc hw_reset updates), thus fixing a > regression in 2.6.27 and therefore hopefully eligible for inclusion into > a stable release. > > v2: Only overwrite initial register values on later revisions of AR5212 > chips. > v3: Use standard macros to manipulate the register. > v4: Use appropriate constants (new to 2.6.28) for register access. > > Signed-off-by: Elias Oltmanns > --- > > drivers/net/wireless/ath5k/initvals.c | 2 ++ > drivers/net/wireless/ath5k/reset.c | 25 ++++++++++--------------- > 2 files changed, 12 insertions(+), 15 deletions(-) > > diff --git a/drivers/net/wireless/ath5k/initvals.c b/drivers/net/wireless/ath5k/initvals.c > index ea2e1a2..ceaa6c4 100644 > --- a/drivers/net/wireless/ath5k/initvals.c > +++ b/drivers/net/wireless/ath5k/initvals.c > @@ -806,6 +806,8 @@ static const struct ath5k_ini_mode ar5212_rf5111_ini_mode_end[] = { > { 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 } }, > { AR5K_PHY(642), > { 0xd03e6788, 0xd03e6788, 0xd03e6788, 0xd03e6788, 0xd03e6788 } }, > + { 0xa228, > + { 0x000001b5, 0x000001b5, 0x000001b5, 0x000001b5, 0x000001b5 } }, > { 0xa23c, > { 0x13c889af, 0x13c889af, 0x13c889af, 0x13c889af, 0x13c889af } }, > }; > diff --git a/drivers/net/wireless/ath5k/reset.c b/drivers/net/wireless/ath5k/reset.c > index 8f18868..8fdb092 100644 > --- a/drivers/net/wireless/ath5k/reset.c > +++ b/drivers/net/wireless/ath5k/reset.c > @@ -537,9 +537,10 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype op_mode, > mdelay(1); > > /* > - * Write some more initial register settings > + * Write some more initial register settings for revised chips > */ > - if (ah->ah_version == AR5K_AR5212) { > + if (ah->ah_version == AR5K_AR5212 && > + ah->ah_phy_revision > AR5K_SREV_PHY_5212) { > ath5k_hw_reg_write(ah, 0x0002a002, 0x982c); > > if (channel->hw_value == CHANNEL_G) > @@ -558,19 +559,13 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype op_mode, > else > ath5k_hw_reg_write(ah, 0x00000000, 0x994c); > > - /* Some bits are disabled here, we know nothing about > - * register 0xa228 yet, most of the times this ends up > - * with a value 0x9b5 -haven't seen any dump with > - * a different value- */ > - /* Got this from decompiling binary HAL */ > - data = ath5k_hw_reg_read(ah, 0xa228); > - data &= 0xfffffdff; > - ath5k_hw_reg_write(ah, data, 0xa228); > - > - data = ath5k_hw_reg_read(ah, 0xa228); > - data &= 0xfffe03ff; > - ath5k_hw_reg_write(ah, data, 0xa228); > - data = 0; > + /* Got this from legacy-hal */ > + AR5K_REG_DISABLE_BITS(ah, AR5K_PHY_DAG_CCK_CTL, > + AR5K_PHY_DAG_CCK_CTL_EN_RSSI_THR); > + > + AR5K_REG_MASKED_BITS(ah, AR5K_PHY_DAG_CCK_CTL, > + 2 << AR5K_PHY_DAG_CCK_CTL_RSSI_THR_S, > + ~AR5K_PHY_DAG_CCK_CTL_RSSI_THR); > > /* Just write 0x9b5 ? */ > /* ath5k_hw_reg_write(ah, 0x000009b5, 0xa228); */ > -- John W. Linville Linux should be at the core linville@tuxdriver.com of your literate lifestyle.