On Fri, Oct 20, 2023 at 12:35 PM Daniel Berlin <dberlin@xxxxxxxxxxx> wrote:
- brcmf_dbg(INFO, "nmode=%d, vhtmode=%d, bw_cap=(%d, %d)\n",
+ brcmf_dbg(INFO,
+ "nmode=%d, vhtmode=%d, bw_cap=(%d, %d, %d), he_cap=(%d, %d)\n",
nmode, vhtmode, bw_cap[NL80211_BAND_2GHZ],
- bw_cap[NL80211_BAND_5GHZ]);
+ bw_cap[NL80211_BAND_5GHZ], bw_cap[NL80211_BAND_6GHZ],
+ he_cap[0], he_cap[1]);
So are these he mac and phy capabilities? ...
No, unfortunately, it's either 1 or 0 on these chips, and all chips i tested.
This is the hardware capability iovar.
In the debug firmware i have access to (not apple's), i do see a
command that looks like it may give the he cap, but i can't find how
it would ever be triggered.
(The iovar code for the iovar above is either always just return 0 or return 1)
There are no obvious iovars that relate, and the absolute latest
bcmdhd hardcodes the he caps, as do infineon's latest ifx code.
:(
I'l hack around see if i can get the caps out of it.
I'll double check other ones.
So, I reached a conclusion on this piece.
This is really an xtlv with subcommands that everyone (including me)
is wrongly treating as a non-xtlv.
The above is really showing you the enable value.
There is also hardware cap value (which is 0/1 as well).
In the 4398/4390 firmware, a "defcap" subcommand was added to the
firmware which can retrieve the default HE capabilities bytes for the
mac and phy and be used to fill them in.
However, it is unsupported in the firmware for earlier chips,
including these chips (or at least, any firmware i've found for it,
apple's or not)
As such, at least for these, STA/AP caps will have to be hardcoded.
I have updated the code to include the subcommands that exist here,
and properly use an xtlv command to retrieve this (it's really a uint8
value).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature