On 2013-05-04 8:50 AM, Oleksij Rempel wrote: > Am 02.05.2013 22:15, schrieb Adrian Chadd: >> Well, let's dig into the firmware a bit more and tidy up how STBC is handled. > > Does it mean, i should change this patch and provide a patch for > firmware too? > I still do not think, changing peer caps i a good idea in any case. > I mena this part of patch: > + if (sta->ht_cap.cap & IEEE80211_HT_CAP_TX_STBC) > + caps |= WLAN_RC_TX_STBC_FLAG; > > > Behaviour with this patch will be fallowing: > - peer provide caps, even if it is RX-STBC12 > - we pass this information to firmware and ratecontroller of FW, do > right decision based on hardware it has. > > You suggestion, if i understand it correctly, is to filter caps: > - if peer provide more than we can, we should tell firmware the value > what we can. So, if peer say it can RX-STBC12, we should tell firmware > that peer is RX-STBC1. > In my opinion, this kind of filter is a source for hidden errors. I think the discussion regarding RX-STBC12 vs RX-STBC1 is purely hypothetical. The hardware that this firmware was designed for only supports sending STBC for MCS0-7. This will not change. Also, there's no reason to tell the firmware about both rx and tx STBC capabilities, the only thing it needs to know is what tells the rate control part to enable/disable STBC. In addition to that, using the WLAN_RC_* flags is wrong, you need to use the ATH_RC_* flags, as this is what ath_rate_newassoc_11n checks for in the firmware. The only STBC related flag that actually gets used (when passed from the driver) is ATH_RC_RX_STBC_FLAG. - Felix -- 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
