lkml.org 
[lkml]   [2023]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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]
\
 
 \ /
  Last update: 2023-10-23 20:10    [W:0.042 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site