Hi Cyril,
> That's not what it does. It is there to determine whether it's a bad
> idea to reload a module. That's quite a different story… And no, between
> two mainloop iterations, that part wouldn't change anyway.
indeed.
I thought the device would be configured after upnics at the beginning or reloading the module + upnics.
sorry for the inconvenience :)
> If we maintain a module/file mapping, we could:
> - decide which modules need to be reloaded, instead of iterating on all
> of them (that's part of the reason why I had this idea in mind in the
> first place, looking around how to “reload dance” was implemented:
> walking through all modules unconditionally);
> - decide that a module is “good to go” as soon as it's been reloaded
> once, i.e. some of the files it requested have been found.
The needed files for my WiFi module BCM43340 / CYW43340 / AP6234 are basically a worst case scenario:
brcmfmac43340-sdio.bin -> required firmware file
(reload)
brcmfmac43340-sdio.txt -> required NVRAM file
(reload)
brcmfmac43340-sdio.clm_blob -> optional and not available for
43340
Depending on the Kernel version the brcmfmac module requests each file first as
brcmfmac43340-sdio.[ManufacturerName]-[ProductName].bin /
.txt /
.clm_blob
and then as fallback:
brcmfmac43340-sdio.bin /
.txt / .clm_blob
-> Debian 11.6: only .txt in
[ManufacturerName]-[ProductName] format
-> Debian 12: all three files in
[ManufacturerName]-[ProductName] format
My manufacturer was kinda lazy and left the
ManufacturerName in BIOS as "To be filled by O.E.M"
->
brcmfmac43340-sdio.To be filled by O.E.M.-Z83.bin
(this is where the spaces came from)
There will be some more prominent devices like the Raspberry Pi 3A / 3B / 4B / M2 / M3 affected with the new Debian version,
I guess it's best to keep the reload dance.