Change Details

The vendor driver doesn't bother with this and it doesn't change performance. My guess is that for modes like AP mode we MAY wantto be able to control the RTS/CTS bandwidth choices rather than letting the firmare do it, but we're not there yet.

The vendor driver doesn't bother with this and it doesn't change performance. My guess is that for modes like AP mode we MAY wantto be able to control the RTS/CTS bandwidth choices rather than letting the firmare do it, but we're not there yet. rtwn: don't set the RTS/CTS primary channel field for RTL8812AU/RTL8821AU According to the rtl8812au reference driver, this seems to control the bandwidth used by lower-bandwidth frames when transmitted in a higher bandwidth channel. For example, transmitting a 20MHz frame on an 80MHz channel (eg in hostap mode) is doable, but you may want to at least duplicate the RTS/CTS exchange across all four 20MHz subchannels, AND perhaps duplicate the 20MHz frame. I haven't fired this up with a spectrum analyser to see what the result is. The vendor driver doesn't bother with this and it doesn't change performance. My guess is that for modes like AP mode we MAY wantto be able to control the RTS/CTS bandwidth choices rather than letting the firmare do it, but we're not there yet. The rtl8812au code in hal/rtl8812a_xmit.c:SCMapping_8812() has the gory details, but then the one place it's used just has it commented out and 0 (ie "do not care") is always programmed in.

The vendor driver doesn't bother with this and it doesn't change performance. My guess is that for modes like AP mode we MAY wantto be able to control the RTS/CTS bandwidth choices rather than letting the firmare do it, but we're not there yet. rtwn: don't set the RTS/CTS primary channel field for RTL8812AU/RTL8821AU According to the rtl8812au reference driver, this seems to control the bandwidth used by lower-bandwidth frames when transmitted in a higher bandwidth channel. For example, transmitting a 20MHz frame on an 80MHz channel (eg in hostap mode) is doable, but you may want to at least duplicate the RTS/CTS exchange across all four 20MHz subchannels, AND perhaps duplicate the 20MHz frame. I haven't fired this up with a spectrum analyser to see what the result is. The vendor driver doesn't bother with this and it doesn't change performance. My guess is that for modes like AP mode we MAY wantto be able to control the RTS/CTS bandwidth choices rather than letting the firmare do it, but we're not there yet. The rtl8812au code in hal/rtl8812a_xmit.c:SCMapping_8812() has the gory details, but then the one place it's used just has it commented out and 0 (ie "do not care") is always programmed in.