Hi,

before more drivers are growing this (LinuxKPI is currently thus I
noticed) beyond the two rtwn chipsets:

sys/dev/rtwn/rtl8192c/r92c_rx.c:                rxs->c_phytype = 
IEEE80211_RX_FP_11B;
sys/dev/rtwn/rtl8192c/r92c_rx.c:                rxs->c_phytype = 
IEEE80211_RX_FP_11G;
sys/dev/rtwn/rtl8192c/r92c_rx.c:                rxs->c_phytype = 
IEEE80211_RX_FP_11NG;
sys/dev/rtwn/rtl8812a/r12a_rx.c:                rxs->c_phytype = 
IEEE80211_RX_FP_11B;
sys/dev/rtwn/rtl8812a/r12a_rx.c:                                rxs->c_phytype 
= IEEE80211_RX_FP_11A;
sys/dev/rtwn/rtl8812a/r12a_rx.c:                                rxs->c_phytype 
= IEEE80211_RX_FP_11G;
sys/dev/rtwn/rtl8812a/r12a_rx.c:                                rxs->c_phytype 
= IEEE80211_RX_FP_11NA;
sys/dev/rtwn/rtl8812a/r12a_rx.c:                                rxs->c_phytype 
= IEEE80211_RX_FP_11NG;
sys/dev/rtwn/rtl8812a/r12a_rx.c:                        rxs->c_phytype = 
IEEE80211_RX_FP_11NA;

These flags are kind-of redundant and along with

#define IEEE80211_RX_F_CCK              0x00001000
#define IEEE80211_RX_F_OFDM             0x00002000

Then we would also have the band in c_band avail given we know
it for the current c_phytype.

I would suggest (as it really simplifies the logic in drivers) to do
these conversions once centrally if we really need them for anything
and simply report the encoding up insetad of what currently is
c_phytype, that is legacy, HT, VHT, .. as that removes a lot of
redundancy and confusion.

And we kind-of have that already as well given we have:
#define IEEE80211_RX_F_HT               0x00004000
#define IEEE80211_RX_F_VHT              0x00008000

So there's redundancy.  I want to understand why?  The c_phytype also
has no notion of AC but then again we do have the VHT flag.

(I am not even going to mention what happens if c_band, c_freq, c_ieee,
the c_pktflags and the current c_phytype would not agree).

It's these things which in parts make net80211 sometimes hard to figure
out because there are three ways to express something at times and it's
not clear at all which ones would be needed (especially if not yet
used).

I would really love us to clean this up before it's being used for
anything to avoid further future work.

There's a lot of "nice to have for reporting" but currently dead code there
which seems to need a bit more tought...

/bz

--
Bjoern A. Zeeb                                                     r15:7

Reply via email to