Hi! Thanks for your constructive feedback!
First, I've done some renaming things. IEEE80211_RATECTL_OPT_* became IEEE80211_RATECTL_CAP_* and options in ieee80211_ratectl became ir_capabilities. As for max4msframelen , I re-added this field and also ported ath_max_4ms_framelen to ieee80211_ratectl. An error is also corrected (about initialization of ir_capabilities). On Tue, Jul 23, 2013 at 10:30 PM, Adrian Chadd <adr...@freebsd.org> wrote: > > * Why do you have IEEE80211_RATECTL_OPT_MULTXCHAIN ? > IEEE80211_RATECTL_OPT_MULTXCHAIN is used in ieee80211_ratectl_hascap_stbc() to assist the determination of whether we can enable STBC. * The reason why I check both the vap/ic and the node bits for HT > capabilities is that they're negotiated. The node bits are what the > remote peer supports. The vap/ic bits are what the local device/vap > supports. So, if the remote node supports STBC and the local node > doesn't, we shouldn't try transmitting short-GI. > uh... I also do the "double check" stuff. Do the ieee80211_ratectl_hascap_* functions do wrong things? And, I'm not very clear about the relation between STBC and short-GI now. It seems that I need some further reading. :) > * In ieee80211_ratectl_complete_rcflags(), enabling RTS/CTS but not > transmitting an 11n rate isn't "right." The 11n hardware supports > per-rate RTS/CTS for non-HT rates. You have to ensure that works. > You've added a capability bit for this (IEEE80211_RATECTL_OPT_MRRPROT) > so you should use it. > Yeah... here my logic messed up. It's corrected. > * the new rate field "options" should be "ir_options", like how the > rest of the fields are prefixed with ir_ > * .. and, nitpicking, it should be "ir_capabilities". > > It's already done. Thanks! Chenchong _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"