Re: [PATCH 03/22] ath9k_hw: Introduce a bool for 25mhz clock and populate it

[Vasanthakumar Thiagarajan <vasanth@atheros.com>]

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.

Vasanth