Luis R. Rodriguez a écrit :
On Thu, Feb 4, 2010 at 1:06 PM, Benoit Papillault
<benoit.papillault@xxxxxxx> 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@xxxxxxxxxx on the commit log entry.
Luis
I think it could be Cc:stable@xxxxxxxxxx, 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
--
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
