On Tue, Apr 12, 2011 at 08:03:06PM +0530, Vasanthakumar Thiagarajan wrote:
> On Tue, Apr 12, 2011 at 07:30:36PM +0530, Vasanth Thiagarajan wrote:
> > > > {
> > > > +#define AR9340_SOC_SEL_25M_40M 0xB80600B0
> > > > +#define AR9340_REF_CLK_40 (1<< 4) /* 0 - 25MHz 1 - 40 MHz */
> > > > +
> > > > struct ath_common *common = ath9k_hw_common(ah);
> > > > int r = 0;
> > > >
> > > > @@ -508,6 +511,14 @@ static int __ath9k_hw_init(struct ath_hw *ah)
> > > >
> > > > ath9k_hw_attach_ops(ah);
> > > >
> > > > + if (AR_SREV_9340(ah)) {
> > > > + if (*((volatile u32 *) AR9340_SOC_SEL_25M_40M)&
> > > > + AR9340_REF_CLK_40)
> > > > + ah->is_clk_25mhz = false;
> > > > + else
> > > > + ah->is_clk_25mhz = true;
> > > > + }
> > > > +
> > > > if (!ath9k_hw_setpower(ah, ATH9K_PM_AWAKE)) {
> > > > ath_err(common, "Couldn't wakeup chip\n");
> > > > return -EIO;
> > > I think this flag should be passed down from the arch code through
> > > platform data instead. Also, dereferencing volatile u32 pointers for
> > > reading registers is somewhat hackish, readl or ioread32 would be better.
> >
> > Yeah, I was also not comfortable with this part of code. I'll fix
> > that. thanks for the comments.
>
> Linville, ralf,
>
> The code change needs to be done in arch code also to fix this
> cleanly. I'm not quite sure about the right way of submitting changes
> in BSP and ath9k driver without possibly breaking the driver due to
> the fact that the change in BSP may not be available along with
> driver change soon in wireless-testing.
Generally we can negotiate to take the related changes through one
tree or the other. How does the arch change look?
John
--
John W. Linville Someday the world will need a hero, and you
linville@xxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
