Re: [PATCH] ath9k: Fix rate table choice

[Benoit PAPILLAULT <benoit.papillault@free.fr>]

Luis R. Rodriguez a écrit :
> On Thu, Feb 4, 2010 at 1:06 PM, Benoit Papillault
> <benoit.papillault@free.fr> wrote:
>   
>> ath9k rate control choose the rate table based on the current channel
>> (if it is ht40 or not). However, it happens that at this stage, the
>> channel is still ht20 even if the peer sta capabilities would later
>> allow ht40. So let's use peer sta capabilities directly.
>>     
>
> Can you clarify this commit log entry a little more, I don't think I
> get it yet. Also, is this a stable fix? If so, please Cc:
> stable@kernel.org on the commit log entry.
>
>   Luis
>   
I think it could be Cc:stable@kernel.org, but I'll leave the decision up 
to you.

In fact, I was using ath9k as a STA connected to an HT40 AP. However, 
only HT20 was displayed in ath9k/phy0/rcstat.
After digging for a while, i found that the current channel 
(sc->hw->conf.channel_type) was indeed an HT20 (or no-ht) channel!

In fact, association is handled as a queued work (from what I 
understood). As such, it uses tmp_channel (see mac80211/work.c). In the 
enable_ht() [mac80211/mlme.c], we update oper_channel_type before 
calling ieee80211_hw_config to call the hw_config driver callback that 
upates conf.channel_type. However, since we are using queued work, 
ieee80211_hw_config will use tmp_channel instead. Then enable_ht calls 
rate_control_rate_update that calls ath9k rate control callbacks ... 
where the channel is ... not HT40! I guess that when the queued work is 
done, the channel is switched again to ht40.

I would appreciate Johannes point of view here...

After applying this patch, ath9k/phy0/rcstat shows both ht20 and ht40 rates.

Regards,
Benoit