Re: [PATCH] brcmfmac: fix setting AP channel with new firmwares
From: Rafał Miłecki <zajec5@gmail.com>
Date: 2016-05-25 21:49:46
Also in:
lkml, netdev
On 25 May 2016 at 23:08, Arend van Spriel [off-list ref] wrote:
On 24-05-16 11:09, Rafał Miłecki wrote:quoted
Firmware for new chipsets is based on a new major version of code internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was based on 7.35.177.56. Currently setting AP 5 GHz channel doesn't work reliably with BCM4366B1. When setting e.g. 36 control channel with VHT80 (center channel 42) firmware may randomly pick one of: 1) 52 control channel with 58 as center one 2) 100 control channel with 106 as center one 3) 116 control channel with 122 as center one 4) 149 control channel with 155 as center one It seems new firmwares require setting AP mode (BRCMF_C_SET_AP) before specifying a channel. Changing an order of firmware calls fixes the problem. This fix was verified with BCM4366B1 and tested for regressions on BCM43602. It's unclear if it's needed (or correct at all) for P2P interfaces so it leaves this code unaffected.In doing so the code reads a bit awkward so if P2P-GO works with the changed order that would be preferable.
I'd prefer to have one code path as well, but my device/firmware doesn't support P2P so I couldn't test it. Could you test it or check firmware code to see if it's safe to change P2P path as well? -- Rafał