Re: IWD 1.27 with brcmfmac not working for roaming

[Arend van Spriel <arend.vanspriel@broadcom.com>]

On 10/12/2024 1:06 PM, Martin Petzold wrote:
> Hi Arend,
> 
> Am 10.10.24 um 10:06 schrieb Martin Petzold:
>> Hi Arend,
>>
>> Am 09.10.24 um 18:50 schrieb Arend Van Spriel:
>>> On October 9, 2024 6:07:16 PM Denis Kenzior <denkenz@gmail.com> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> On 10/9/24 4:43 AM, Martin Petzold wrote:
>>>>> Hi
>>>>>
>>>>> PROBLEM
>>>>>
>>>>> We (still) have some trouble with IWD together with brcmfmac. We 
>>>>> updated
>>>>> firmware for the chip (Infineon CYW43353) to latest version 
>>>>> 11.171.0.24 and also
>>>>
>>>> Ugh :)  That stuff is known to be problematic.  You might want to 
>>>> involve Arend
>>>> in this discussion.
>>>
>>> Is this specifically related to WPA3 or in general? The version does 
>>> not tell me much and I don't have access to Infineon firmware to 
>>> examine. I do know there are two variants floating around regarding 
>>> WPA3-SAE support: 1) supplicant in firmware and 2) using EXT_AUTH. 
>>> The latter is supported in  downstream repo on github, but it has not 
>>> been done in upstream linux-wireless. I did post patches for testing 
>>> last month. 
>>
>> I was able to migrate to NXP kernel 6.1.36 with Debian bookworm rootfs 
>> containing IWD 2.3. I will try also to build IWD 2.22 later. If this 
>> setup / configuration makes sense I would go to roaming environments 
>> again. However, I have the following questions and please find the 
>> configuration and logs below:
>>
>> 1. Why does brcmfmac report "Using regulatory domain US" even though I 
>> have set "ccode=EU" and "regrev=116" in /lib/firmware/brcm/ 
>> brcmfmac4339-sdio.txt?
> 
> I had an entry in the device tree (laird,regdomain = "US"), which seems 
> to be stronger than the value in the brcmfmac4339-sdio.txt. Can you 
> confirm?
> 
> Now I don't get any output like "Using regulatory domain ..." any more. 
> How can I now be sure that EU (ETSI) is used?

I really have no clue. This is not in the upstream driver so I assume 
you are also using some Infineon flavor of the brcmfmac driver. That 
device tree entry is definitely not in the bindings specification.

>> 2. Is it the best approach to use firmware for Laird LWB5 / CYW43353 
>> from their Git repository (laird-lwb5-etsi-firmware-11.171.0.24.tar.bz2)?
> 
> Here I switched to newer version 12.29.0.22. I assume this firmware is 
> the correct one and should work with the Kernel brcmfmac driver 
> (6.1.36), right?

Sorry. No answer to that. I have no knowledge about distribution 
packages from Laird.

>> 3. If you say roaming can be handled by firmware (driver?) OR daemon 
>> (IWD), what is the best approach and how to configure it?
> 
> This question is still open for me. In general the question, will 
> brcmfmac work with the laird firmware and IWD stable (really good) also 
> for roaming?

In general it is best to let firmware take care of roaming. You can try 
using the module parameter 'roam_off' and see how well IWD takes care of 
roaming. I have never used IWD.

>> 4. Is it valid to always use brcm-patchram-plus to load the firmware 
>> on every boot?

What is brcm-patchram-plus?

>> 5. I see the following error (more log below). What is going wrong?
>>
>> Okt 10 09:38:19 tavla kernel: brcmfmac mmc0:0001:1: Direct firmware 
>> load for brcm/brcmfmac4339-sdio.variscite,imx8mp-var-dart.bin failed 
>> with error -2
>> Okt 10 09:38:19 tavla kernel: brcmfmac mmc0:0001:1: Direct firmware 
>> load for brcm/brcmfmac4339-sdio.clm_blob failed with error -2
>> Okt 10 09:38:19 tavla kernel: brcmfmac: brcmf_c_process_clm_blob: no 
>> clm_blob available (err=-2), device may have limited channels available

Nothing wrong here except that it does not find a clm_blob file.

> What about the "clm_blob". Is it required in file system for 4339? (I 
> don't want to have limited channels)

What channels are reported if you use the iw utility?

Regards,
Arend