linux-kernel - Re: [PATCH 2/5] [brcmfmac] Add support for 6G bands

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <18b5db7cac0.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
Date:   Mon, 23 Oct 2023 20:06:48 +0200
From:   Arend Van Spriel <arend.vanspriel@...adcom.com>
To:     Daniel Berlin <dberlin@...rlin.org>
CC:     Arend van Spriel <aspriel@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        <linux-wireless@...r.kernel.org>,
        <brcm80211-dev-list.pdl@...adcom.com>,
        <SHA-cyfmac-dev-list@...ineon.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] [brcmfmac] Add support for 6G bands


On October 23, 2023 1:41:34 PM Daniel Berlin <dberlin@...rlin.org> wrote:

> On Fri, Oct 20, 2023 at 12:35 PM Daniel Berlin <dberlin@...rlin.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.

Gr. AvS




Download attachment "smime.p7s" of type "application/pkcs7-signature" (4219 bytes)