[brcmfmac] connman/iwd unreliable rescan of SSIDs

Start by reproducing the intermittent reconnect with connman, iwd, and the brcmfmac driver after the router radio returns. Inspect drivers/net/wireless/broadcom/brcm80211/brcmfmac and cfg80211.c, compare the reported firmware and kernel versions, and collect dmesg output during rescans. Done means the driver consistently rescans and reconnects after the SSID reappears.

Is this the right place for my bug report?
This repository contains the Linux kernel used on the Raspberry Pi. If you believe that the issue you are seeing is kernel-related, this is the right place. If not, we have other repositories for the GPU firmware at github.com/raspberrypi/firmware and Raspberry Pi userland applications at github.com/raspberrypi/userland. If you have problems with the Raspbian distribution packages, report them in the github.com/RPi-Distro/repo. If you simply have a question, then the Raspberry Pi forums are the best place to ask it.

This kind of covers both the kernel and firmware, but is mostly focused on the driver part.

Describe the bug
When using connman and iwd on my Rpi, I sometimes get a re-connection when the SSID disappears then reappears (router reboot) but it is inconsistent.

To reproduce
Build kernel with the iwd flags set https://iwd.wiki.kernel.org/gettingstarted
install connman and iwd
un-install wpa_supplicant!!
Create a config file in /var/lib/connman for your local SSID https://www.mankier.com/5/connman-service.config
connect to the SSID
Reboot the router or turn off then on the radio on the router and see if the RPi reconnects.

Expected behaviour
After the radio comes back online, it should connect pretty quickly

Actual behaviour
Intermittent behavior. Sometimes it re-scans and connects, sometimes it just sits and never re-scans. If it re-scans, it will reconnect.

System
Currently Arch Linux running Kernel 5.4.70. Am in process of building a separate card with Raspi OS Lite and building the kernel with the proper configs set and will test there as well as I believe that would be the preferred test platform

• Which model of Raspberry Pi? Pi 3B, 3B+, Zero
• Which OS and version? Current Arch Arm v6/v7/Aarch64 linux-5.4.70, Currently building RaspiOS test bed
• Which firmware version (vcgencmd version)? 20200820
• Which kernel version (uname -a)? linux-5.4.70

Logs
If applicable, add the relevant output from dmesg or similar.
Nothing shows in the log. It just doesn't always rescan. from discussion with connman and iwd developers, this may be a driver issue with the brcmfmac driver
Additional context
Add any other relevant context for the problem.
There is a lot of discussion of the brcmfmac firmware and that different versions have different capabilities. I have hacked in the latest broadcom firmware onto my Pis from the Cypress update form 20200625:

Originally:
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
Updated to:
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Sep 18 2020 02:27:58 version 7.45.221 (3a6d3a0 CY) FWID 01-bbd9282b

It will actually rescan once, but then stalls and will not rescan. I wonder is if the firmware and driver from cypress may be needed to function correctly. The Cypress update package has the firmware and the driver. I have seen many discussions online about updating the firmware, but none about updating the driver. I spent a few hours trying to get this to build either as a module by itself or with the full kernel package and it fails every time. I am certain that I am not patching properly with all the files and configs it needs.
https://community.cypress.com/docs/DOC-21490
The zip file has within it the firmware and also a 5.4.18 module backport. When I compare the files in the brcmfmac directory, there are a lot of differences to what is in the 5.70 kernel as well as the current upstream kernel. It is as if none of this has been incorporated at all in the kernel tree. I have attempted a patch with the files in the /drivers/net/broadcom/brcm80211/brcmfmac and other files from that tree and get to this and it stops:

$ make M=drivers/net/wireless/broadcom/brcm80211
CC [M] drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.o
In file included from drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:12:
./include/net/cfg80211.h: In function ‘wiphy_net’:
./include/net/cfg80211.h:4693:9: error: implicit declaration of function ‘possible_read_pnet’ [-Werror=implicit-function-declaration]
4693 | return possible_read_pnet(&wiphy->_net);
| ^~~~~~~~~~~~~~~~~~
./include/net/cfg80211.h:4693:9: warning: returning ‘int’ from a function with return type ‘struct net *’ makes pointer from integer without a cast [-Wint-conversion]
4693 | return possible_read_pnet(&wiphy->_net);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/net/cfg80211.h: In function ‘wiphy_net_set’:
./include/net/cfg80211.h:4698:2: error: implicit declaration of function ‘possible_write_pnet’ [-Werror=implicit-function-declaration]
4698 | possible_write_pnet(&wiphy->_net, net);
| ^~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:266: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.o] Error 1
make[1]: *** [scripts/Makefile.build:500: drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
make: *** [Makefile:1732: drivers/net/wireless/broadcom/brcm80211] Error 2

with a bit of help, I may get it to build and can see if it does anything differently.