rtwn: refactor out the r92c path protection decision / configuration

[adrian]

Summary

• refactor out the r92c path protection (RTS/CTS) decision
• update the configuration code to ignore setting RTS/CTS for now if firmware rate control is enabled.

This works on RTL8192CU both with firmware rate control and driver
rate control. However, there is no RTS/CTS for firmware rate control -
the awareness will need to be added in a subsequent commit.

Locally tested:

• RTL8192CU, STA - firmware and net80211 rate control

[adrian]

Implement rts/cts programming w/ firmware rate control config.

(This isn't enough by itself; the logic that SELECTS whether to do
rts/cts still needs updating.)

[adrian]

update with working protection mode logic for firmware rate control

[fuz]

sys/dev/rtwn/rtl8192c/r92c_tx.c

114–120

Avoid code duplication of the common ridx assignment.

312

Booleans should not be compared against true/false, use boolean operators instead.

324

This seems wrong. prot is unconditionally overwritten at this point. What is the point of the previous if statements? Is perhaps an else missing?

339

The control flow of this function is confusing and not obvious. Could you perhaps use an early return pattern instead of repeatedly assigning to prot?

[bz]

@adrian, do you want to update according @fuz 's requests?

sys/dev/rtwn/rtl8192c/r92c_tx.c

114–120

? : go at he end of the line ; also there is an extra ; in there somewhere...

[adrian]

sys/dev/rtwn/rtl8192c/r92c_tx.c

324

This seems wrong. prot is unconditionally overwritten at this point. What is the point of the previous if statements? Is perhaps an else missing?

oops, left in debugging. :-) I'll remove it.

339

I can't because the last check (rts/cts threshold) needs to override the others.

[adrian]

address fuz/bz feedback

[adrian]

oops, this one too