urtwn(4): fix rssi calculation

[avos]

Test Plan

Scan results from different devices:
WUSB54GCv1 (rum):
0x00000 00:1a:70:9e:9a:70 1 54M -76:-95 100 EP RSN
wpi0 00:19:d2:01:02:03 1 54M -75:-95 100 ES WME

Intel 3945BG (wpi):
0x00000 00:1a:70:9e:9a:70 1 54M -70:-95 100 EP RSN
rum0 00:1d:7e:01:02:03 7 54M -69:-95 100 ES WME

RTL8188EU (urtwn) (without this patch):
0x00000 00:1a:70:9e:9a:70 1 54M -140:-95 100 EP RSN
wpi0 00:19:d2:01:02:03 1 54M -140:-95 100 ES WME
rum0 00:1d:7e:01:02:03 7 54M -140:-95 100 ES WME

RTL8188EU (urtwn) (with this patch):
0x00000 00:1a:70:9e:9a:70 1 54M -81:-95 100 EP RSN
wpi0 00:19:d2:01:02:03 1 54M -70:-95 100 ES WME
rum0 00:1d:7e:01:02:03 7 54M -64:-95 100 ES WME

[adrian]

Ok, so what's the difference between R88 and R92? Like, should the R88 chips be using R92 method, or is the R88 method we have broken?

[avos]

In D3820#78814, @adrian wrote:

Ok, so what's the difference between R88 and R92? Like, should the R88 chips be using R92 method, or is the R88 method we have broken?

Even if the R88 method is separate & broken - I don't know how to fix it (and R92 method seems to be good enough for R88 chips).

[avos]

I think, that r88e_rx_cck structure is wrong (for example, sig_qual field contains current channel number + it is here for all frames, not only for CCK)

[avos]

OK, this way is not correct too. I will fix this soon.

[adrian]

Heh, so what did you find?

[avos]

1. The URTWN_RSSI macro in inappropriate here - since urtwn_get_rssi()/urtwn_r88e_get_rssi() returns negative value, in most cases this macro will cause overflow.
2. As I have said previously, 3rd byte is channel and 4th is always (or not?) zero. After adding two additional fields here, restored urtwn_r88e_get_rssi() call starts producing more realistic values (almost the same as from other NICs).

[adrian]

if kevin is okay with this, then I'm okay!