1:  876dad796365 ! 1:  ff144ec13e74 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.
     
    -    Set the bit, if it is clear, before downloading the firmware on
    -    BCM43602 boards with Apple's subsystem vendor ID. 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. This was only seen on a
    -    MacBookPro14,3; the check covers all Apple BCM43602 boards on the
    -    assumption that their platform firmware sets the bit the same way.
    +    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
    +    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.
     
         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.
    +    nothing is written. Not tested with this patch on a MacBookPro14,2.
     
         Signed-off-by: Sergey Armodin <dolph-in@yandex.ru>
     
    @@ drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c: static void brcmf_pcie_
     +/* ChipCommon chipcontrol bit selecting the discrete FEM control pin mode */
     +#define BRCMF_CC_CHIPCTL_4360_DISCRETE_FEMCTRL_MODE	BIT(4)
     +
    -+/* On a MacBookPro14,3 with a BCM43602, 5 GHz only works with the discrete
    -+ * FEM control pin mode selected in the ChipCommon chipcontrol register. The
    -+ * bit is set after a reboot, but a power-on reset of the chip (e.g. over S3
    -+ * on battery) clears it and the firmware does not set it again. Other Apple
    -+ * BCM43602 boards are assumed to be set up the same way. Restore the bit
    -+ * before the firmware is started.
    ++/* On the Apple boards below, 5 GHz on the BCM43602 only works with the
    ++ * discrete FEM control pin mode selected in the ChipCommon chipcontrol
    ++ * register. The bit is set after a reboot, but a power-on reset of the chip
    ++ * (e.g. over S3) clears it and the firmware does not set it again. Restore
    ++ * it before the firmware is started. Other Apple boards may not use this
    ++ * mode (a MacBookPro11,5 boots with the bit clear), so they are left alone.
     + */
     +static void brcmf_pcie_43602_apple_femctrl(struct brcmf_pciedev_info *devinfo)
     +{
    ++	const struct pci_dev *pdev = devinfo->pdev;
     +	u32 val;
     +
    -+	if (devinfo->pdev->subsystem_vendor != PCI_VENDOR_ID_APPLE)
    ++	if (pdev->subsystem_vendor != PCI_VENDOR_ID_APPLE)
    ++		return;
    ++
    ++	switch (pdev->subsystem_device) {
    ++	case 0x0157:	/* MacBookPro14,2, possibly others */
    ++	case 0x0173:	/* MacBookPro14,3 */
    ++		break;
    ++	default:
     +		return;
    ++	}
     +
     +	brcmf_pcie_select_core(devinfo, BCMA_CORE_CHIPCOMMON);
     +	val = READCC32(devinfo, chipcontrol);