kernel/linux.git/drivers/net/wireless/broadcom, branch v7.2-rc1

b43: add RF power offset for N-PHY r8 + radio 2057 r8

2026-06-10T08:27:56+00:00

Add the 2.4 GHz RF power offset table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher. b43_ntab_get_rf_pwr_offset_table() currently dispatches on phy->rev == 17 (radio_rev 14) and phy->rev == 16 (radio_rev 9) for 2.4 GHz. phy->rev == 8 falls through and the function logs: b43-phyX ERROR: No 2GHz RF power table available for this device Add a phy->rev == 8 / radio_rev == 8 case returning the new table. The values are sourced from the proprietary Broadcom wl driver's nphy_papd_padgain_dlt_2g_2057rev5 array. Reusing the rev 5 values is structurally appropriate: the IPA TX gain table added by the preceding patch in this series shares the low 24 bits of every entry with rev 5 - same gain step amplitudes, only the PAD-gain selector byte differs. b43's pad_gain extraction in b43_nphy_tx_pwr_ctl_init() reads bits 19..23 of the gain entry, which sit in the shared low-24-bit range; the same gain index therefore maps to the same physical PAD gain code on both revisions and warrants the same per-index dB offset. Note that b43_nphy_tx_gain_table_upload() currently has a "TODO: Enable this once we have gains configured" early-return for phy->rev >= 7. With that early-return in place, this table is fetched (silencing the b43err that would otherwise abort PHY init) but its values are not yet written to MMIO. Resolving the TODO is a future, separate task. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri Acked-by: Michael Büsch Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-7-464566194d47@gmail.com Signed-off-by: Johannes Berg

b43: add channel info table for N-PHY r8 + radio 2057 r8

2026-06-10T08:27:55+00:00

Add the 2.4 GHz channel info table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher in r2057_get_chantabent_rev7(). The dispatcher's case 8 currently handles radio_rev == 5 only. For radio_rev == 8 both output pointers stay NULL, b43_nphy_set_channel() returns an error and channel switch to the default channel fails. The new b43_nphy_chantab_phy_rev8_radio_rev8[] is 14 entries covering the standard 2.4 GHz channel set (2412..2472 in 5 MHz steps, plus 2484 for channel 14). Values extracted from an MMIO dump of the proprietary Broadcom wl driver running on BCM6362 silicon (wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri Acked-by: Michael Büsch Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-6-464566194d47@gmail.com Signed-off-by: Johannes Berg

b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8

2026-06-10T08:27:54+00:00

Add the 2.4 GHz IPA TX gain table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher. b43_nphy_get_ipa_gain_table() in tables_nphy.c currently handles case 8 only for radio_rev == 5; radio_rev == 8 falls through and the function logs: b43-phyX ERROR: No 2GHz IPA gain table available for this device b43-phyX ERROR: PHY init: Channel switch to default failed leaving b43_phy_init() to return an error and core_init to abort before the MAC is enabled. The high byte of every entry differs from the rev 5 sibling (0x40 vs 0x30): different PAD-gain code prefix for the rev 8 front-end. The low 24 bits coincide with rev 5 across the whole table - the gain step amplitudes are the same, only the PAD-gain selector prefix changes. Values extracted from an MMIO dump of the proprietary Broadcom wl driver running on BCM6362 silicon (wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri Acked-by: Michael Büsch Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-5-464566194d47@gmail.com Signed-off-by: Johannes Berg

b43: support radio 2057 rev 8

2026-06-10T08:27:53+00:00

Add support for radio 2057 revision 8, paired with N-PHY rev 8 on the Broadcom BCM6362 single-die integrated 2.4 GHz wireless block. Three correlated changes are needed for the same chip: - main.c: the radio_rev allow-list under B43_PHYTYPE_N currently accepts radio 2057 revisions 9 and 14 only; extend to include rev 8. - radio_2057.c: the existing r2057_rev8_init[] is a 54-entry stub declared inside a TODO comment block and never referenced from r2057_upload_inittabs(). Replace it with the full 412-entry register set actually programmed by the proprietary Broadcom wl driver on this radio. I couldn't find the origin of the original 54-entry stub - 8 of its entries do not appear at all in the rev 8 register set and 7 more carry different values. Loading it instead of using the real table leaves the radio hanging producing a "Microcode not responding" timeout. - radio_2057.c: r2057_upload_inittabs() case 8 handles radio_rev 5 and 7 only; add the radio_rev == 8 branch pointing at the new table. The init table is extracted from an MMIO dump of the radio register set programmed during proprietary driver initialisation on BCM6362 silicon (Broadcom wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri Acked-by: Michael Büsch Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-4-464566194d47@gmail.com Signed-off-by: Johannes Berg

b43: route d11 corerev 22 to 24-bit indirect radio access

2026-06-10T08:27:52+00:00

Rev 22 backports the older 802.11 core but pairs it with a radio in the 2057 family, which requires the 24-bit indirect path. With the current dispatch, corerev 22 falls into the legacy 4-wire branch, reads garbage for radio_id, and bails out with -EOPNOTSUPP at the "FOUND UNSUPPORTED RADIO" branch below. brcmsmac handles the same silicon family with the equivalent dispatch in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/ phy_cmn.c read_radio_reg() and write_radio_reg(): if ((D11REV_GE(pi->sh->corerev, 24)) || (D11REV_IS(pi->sh->corerev, 22) && (pi->pubpi.phy_type != PHY_TYPE_SSN))) { /* radioregaddr / radioregdata (indirect) */ } else { /* phy4waddr / phy4wdatalo (legacy) */ } b43 does not support SSN/SSLPN PHYs - they are rejected earlier in b43_phy_versioning() at the "unsupported PHY type" switch - so just adding the check corerev == 22 will do. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri Acked-by: Michael Büsch Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-3-464566194d47@gmail.com Signed-off-by: Johannes Berg

b43: add d11 core revision 0x16 to id table

2026-06-10T08:27:51+00:00

Add d11 core revision 0x16 (= 22) to the b43 bcma device id table. The b43 bcma id table covers d11 revisions 0x11, 0x15, 0x17, 0x18, 0x1C, 0x1D, 0x1E, 0x28 and 0x2A. Revision 0x16 belongs to the same N-PHY family as revisions 0x17 and 0x18 (radio 2057) and needs no new PHY or radio code beyond the radio_rev 8 dispatcher entries added later in this series - only the device id entry is missing. Without it bcma scan enumerates the 802.11 core but no driver binds. The revision is used by the Broadcom BCM6362 single-die integrated 2.4 GHz wireless block found in xDSL SoCs. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri Acked-by: Michael Büsch Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-2-464566194d47@gmail.com Signed-off-by: Johannes Berg

b43: add firmware mappings for rev22

2026-06-10T08:27:48+00:00

add the specific firmware mappings for rev22, and drop comments wondering about rev22 initvals Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri Acked-by: Michael Büsch Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-1-464566194d47@gmail.com Signed-off-by: Johannes Berg

wifi: brcmfmac: flowring: simplify flow allocation

2026-06-10T06:34:24+00:00

Use a flexible array member and kzalloc_flex to combine allocations. Simplifies code slightly. Add __counted_by for extra runtime analysis. Signed-off-by: Rosen Penev Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260608051102.6698-1-rosenp@gmail.com Signed-off-by: Johannes Berg

wifi: brcm80211: change current_bss to value

2026-06-10T06:34:08+00:00

Change to a single allocation and remove some boilerplate. Signed-off-by: Rosen Penev Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260608052854.11718-1-rosenp@gmail.com Signed-off-by: Johannes Berg

net: Consistently define pci_device_ids using named initializers

2026-05-13T01:16:34+00:00

... and PCI device helpers. The various struct pci_device_id arrays were initialized mostly by one the PCI_DEVICE macros and then list expressions. The latter isn't easily readable if you're not into PCI. Using named initializers is more explicit and thus easier to parse. Also use PCI_DEVICE* helper macros to assign .vendor, .device, .subvendor and .subdevice where appropriate and skip explicit assignments of 0 (which the compiler takes care of). The secret plan is to make struct pci_device_id::driver_data an anonymous union (similar to https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/) and that requires named initializers. But it's also a nice cleanup on its own. This change doesn't introduce changes to the compiled pci_device_id arrays. Tested on x86 and arm64. Reviewed-by: Jijie Shao Acked-by: Arend van Spriel Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Machata # for mlxsw Acked-by: Jacob Keller Acked-by: Johannes Berg Signed-off-by: Uwe Kleine-König (The Capable Hub) Forwarded: id:76da4f44d48bdde84580963862bf9616bee5c9e9.1778149923.git.u.kleine-koenig@baylibre.com (v2) Reviewed-by: Michael Grzeschik Link: https://patch.msgid.link/20260511090023.1634387-6-u.kleine-koenig@baylibre.com Signed-off-by: Jakub Kicinski