On Thu, Nov 06, 2025 at 08:02:37PM +0000, Sebastian wrote: > "Broadcom BCM4313" rev 0x01 at pci3 dev 0 function 0 not configured
This is an old broadcom device which uses the brcmsmac driver on Linux. The code of this driver is complicated, massive (larger than all our existing wifi drivers combined), and it cannot be reviewed in a reasonable way because Broadcom has obfuscated human-readable names of device-side data structures by replacing them with magic numbers. See the code in this file for example: https://github.com/torvalds/linux/blob/master/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c Scroll down a bit and discover things like: mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0)); mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8)); mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0)); mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8)); mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0)); mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8)); mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0)); mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8)); mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0)); mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8)); In proper source code these would be macros which at least hint at what each of these registers and values represent. I suspect that Broadcom does posess internal code which is readable, but they apply some post-processing before submitting patches to Linux. Another example: switch (field) { case (0x1 << 1): en_addr = (core_num == 0) ? 0xe7 : 0xec; val_addr = (core_num == 0) ? 0x7a : 0x7d; val_mask = (0x1 << 0); val_shift = 0; break; case (0x1 << 2): en_addr = (core_num == 0) ? 0xe7 : 0xec; val_addr = (core_num == 0) ? 0x7a : 0x7d; val_mask = (0x1 << 1); val_shift = 1; break; case (0x1 << 3): en_addr = (core_num == 0) ? 0xe7 : 0xec; val_addr = (core_num == 0) ? 0x7a : 0x7d; val_mask = (0x1 << 2); val_shift = 2; break; It is impossible to make sense of this in a reasonable amount of time without vendor documentation which we do not have access to. The Linux folks have accepted this obfuscation, but it is not acceptable to me at least. This is not code I would want to take responsibility for. On other broadcom devices which we do support in the bwfm driver, what the above code is doing is instead handled by firmware which runs on the device. And code in the corresponding Linux driver is not obfuscated. So in that case we don't have to deal with any of this nonsense. I am sorry but unless some other developer would want to endure dealing with this mess, your best bet will be either using an external USB wifi device or replacing the card with one that works. iwm Intel 7260 cards should exist in compatible form factors.
