You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Address @tchebb's second review pass:
* Named constants for chip IDs (BRCM_CC_43430_CHIP_ID, _43439_, _4345_)
matching Linux brcm_hw_ids.h; replace bare 43430 / 43439 / 0xa9a6
/ 0x4345 throughout. This also fixes the brcmfmac_init() CLM gate
and brcmfmac_chip_cm3_set_passive() bank-3 gate, both of which
were checking the same chip ID twice (43430 == 0xa9a6) and so
never fired on CYW43439.
* Drop the chip-ID gate on the CLM blob upload. Linux brcmfmac
doesn't gate this -- it just uploads if a blob is provided,
silently skips if not. Mirror that: skip when brcmfmac_clm_blob_len
is zero. Removes the hallucinated "firmware refuses the iovar"
rationale.
* Wire the CLM blob into the build system the same way as firmware
and NVRAM: new WIFI_BRCMFMAC_CLM_FILE Kconfig string (default
empty), CMake generates brcmfmac_clm_blob.inc from the named
blob, brcmfmac_fw_blob.c #include's it. Empty string -> empty
.inc -> zero-length array -> upload skipped. Also fixes a latent
link error: brcmfmac_clm_blob[] was declared extern but never
defined.
* Named constants for the WL_REG_ON pulse delays (was bare 10/250),
matching WHD's 20/150 values for this chip family.
* Named constants for the dload header flags (BRCMF_DL_BEGIN,
_DL_END, _DL_CRC_IN_HDR, _DL_TYPE_CLM) and the CLM upload chunk
size, replacing magic 2/4/(1<<12)/512 ints in brcmfmac_process_clm_blob.
* Bump the NVRAM scratch buffer to 4 KiB so it covers the largest
NVRAM currently in linux-firmware (3099 bytes after the footer).
Signed-off-by: Jonathan E. Peace <jep@alphabetiq.com>
0 commit comments