Messages in this thread | | | From | Arend Van Spriel <> | Date | Mon, 23 Oct 2023 20:09:16 +0200 | Subject | Re: [PATCH 2/5] [brcmfmac] Add support for 6G bands |
| |
On October 23, 2023 8:06:52 PM Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> On October 23, 2023 1:41:34 PM Daniel Berlin <dberlin@dberlin.org> wrote: > >> On Fri, Oct 20, 2023 at 12:35 PM Daniel Berlin <dberlin@dberlin.org> 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. > > So they adopted the same subcommand I added in our firmware. Hopefully it > is a true copy. > >> 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). > > I do have patch lying around here that add xtlv support to fwil.c. Or did I > already submit that.
It's already there indeed :-D > Gr. AvS
[unhandled content-type:application/pkcs7-signature] | |