1: ff144ec13e74 ! 1: 1b9723e2618d wifi: brcmfmac: pcie: restore FEM control pin mode on Apple BCM43602 @@ Commit message setting bit 4 alone before the firmware is downloaded is enough to make 5 GHz work again.  - A MacBookPro14,2 (subsystem 106b:0157) was reported to behave the - same way, over S3 on AC power as well as on battery: with the driver + A MacBookPro14,2 (subsystem 106b:0157) was reported to behave the same + way, over S3 on AC power as well as on battery: with the driver unbound, chipcontrol read 0x01400090 after a boot, 0 after S3 and 0x01000000 once the firmware had run again, and setting bit 4 from - user space before loading the driver made 5 GHz work again. A - MacBookPro11,5 (subsystem 106b:0152), on the other hand, boots with + user space before loading the driver made 5 GHz work again. + + A MacBookPro13,3 (subsystem 106b:015a) was reported to lose the bit as + well, but only over S3 off the charger: with the driver unbound, + chipcontrol read 0x01400090 after a boot and 0 after S3 with the + charger unplugged for some or all of the sleep, but kept bit 4 over S3 + on the charger. After S3 on battery, joins failed with status 16, and + setting bit 4 from user space before loading the driver made 5 GHz + work again. + + A MacBookPro11,5 (subsystem 106b:0152), on the other hand, boots with chipcontrol 0x0100000c, bit 4 clear, and 5 GHz works there, so not every Apple BCM43602 board uses this mode.  Set the bit, if it is clear, before downloading the firmware, but only - for the MacBookPro14,2 and MacBookPro14,3 subsystem IDs. Subsystem ID - 0x0157 may not be unique to the MacBookPro14,2: it is also the ID that - the module on the MacBookPro14,3 reports after a reset, until the - platform firmware rewrites it to 0x0173, so other boards with the same - module may match too. When the firmware is lost over a resume, - brcmfmac removes and probes the device again, so this covers S3 as - well as a driver reload. + for the MacBookPro13,3, MacBookPro14,2 and MacBookPro14,3 subsystem + IDs. Subsystem ID 0x0157 may not be unique to the MacBookPro14,2: it + is also the ID that the module on the MacBookPro14,3 reports after a + reset, until the platform firmware rewrites it to 0x0173, so other + boards with the same module may match too. When the firmware is lost + over a resume, brcmfmac removes and probes the device again, so this + covers S3 as well as a driver reload.  Tested on a MacBookPro14,3 with firmware 7.35.177.61: after power cycling the slot and after S3 on battery the driver sets the bit and 5 GHz associates again; after a normal boot the bit is already set and - nothing is written. Not tested with this patch on a MacBookPro14,2. + nothing is written. Not tested with this patch on a MacBookPro13,3 or + a MacBookPro14,2.  + Tested-by: Angel Lindo # MacBookPro14,3 Signed-off-by: Sergey Armodin   ## drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ## @@ drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c: static void brcmf_pcie_  +  + switch (pdev->subsystem_device) {  + case 0x0157: /* MacBookPro14,2, possibly others */ ++ case 0x015a: /* MacBookPro13,3 */  + case 0x0173: /* MacBookPro14,3 */  + break;  + default: