Page MenuHomeFreeBSD

rtwn: try enforcing net80211 regulatory / txpower limits for 11n chips
ClosedPublic

Authored by adrian on Dec 8 2024, 3:57 PM.
Referenced Files
Unknown Object (File)
Thu, Dec 26, 5:54 AM
Unknown Object (File)
Thu, Dec 26, 2:00 AM
Unknown Object (File)
Dec 25 2024, 11:57 AM
Unknown Object (File)
Dec 25 2024, 7:27 AM
Unknown Object (File)
Dec 25 2024, 6:31 AM
Unknown Object (File)
Dec 25 2024, 1:54 AM
Unknown Object (File)
Dec 21 2024, 8:57 AM
Unknown Object (File)
Dec 20 2024, 12:53 AM
Subscribers

Details

Summary

This is an attempt to reverse engineer what the actual transmit power
calculations are doing and apply net80211 limits on them. It doesn't
look as simple as just applying the check at the end - there are plenty
of places where offsets are calculated between different PHY modes and
1 / 2 antenna MCS transmit rates.

There are also some places where the offset being added is negative,
so handle the potential underflow so when things hit 0, they don't
just wrap and cause the maximum transmit power into the registers.

This is being done to aide in power/performance debugging - if there
are issues with the transmit power being wrongly calculated and are too
high, the output waveform will be distorted and it will effect performance.
Being able to drop the transmit power by a few dB here and there can
quickly identify if this is happening (because suddenly higher MCS
rates / OFDM rates suddenly work better!)

I've tested each NIC through the transmit power values from 0 dBm
to 30dBm via ifconfig (and they're all capped far before that,
normally around 20-25dBm) and they're not underflowing.

Locally tested:

  • RTL8192CU, STA
  • RTL8192EU, STA
  • RTL8188EU, STA

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

adrian requested review of this revision.Dec 8 2024, 3:57 PM
This revision is now accepted and ready to land.Dec 12 2024, 6:14 PM
bz requested changes to this revision.EditedDec 18 2024, 10:38 AM
bz added a subscriber: bz.

Commit message: "to aid" (without e; aide is a noun).

Some rNNxx_attach.c seems missing (initialization) again/still or this patch is not incremental to a previous one in the stack which means the stack as-is was never tested to even build?

I take that back; the 92eu is added here which was missing in the previous change and that's why the value is added and not changed. Best to be migrated to D47979 to avoid further confusion.

This revision now requires changes to proceed.Dec 18 2024, 10:38 AM

Ignoring nose the rest seems fine, so fixing the mix between the two Dxxxx and we are good.

sys/dev/rtwn/rtl8188e/r88e_chan.c
148

Noise. The dot at the end seems to be fine be me.

sys/dev/rtwn/rtl8192e/r92e_chan.c
121

do we need this temp variable?

127

In case you change the variable away above also remove the blank line here.

sys/dev/rtwn/rtl8192e/r92e_chan.c
121

I think it should be ok to delete it; power[ridx] is uint8_t as it's hardware, pwr_diff in the EEPROM is signed (int8_t) and is likely negative here in all cases, so as long as I use an int8_t pwr below (and delete the blank line as asked) it SHOULD be ok.

In D47987#1097419, @bz wrote:

Commit message: "to aid" (without e; aide is a noun).

Some rNNxx_attach.c seems missing (initialization) again/still or this patch is not incremental to a previous one in the stack which means the stack as-is was never tested to even build?

I take that back; the 92eu is added here which was missing in the previous change and that's why the value is added and not changed. Best to be migrated to D47979 to avoid further confusion.

yup, fixed the initialisation so now it looks consistent (replacing the no-op)

updated, please review!

This revision is now accepted and ready to land.Dec 18 2024, 10:16 PM