Search Linux Wireless

Re: [PATCH v2] brcmfmac: Use firmware_request_nowarn for the clm_blob

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 10-01-19 09:18, Chi-Hsien Lin wrote:


On 01/07/2019 9:33, Hans de Goede wrote:
The linux-firmware brcmfmac firmware files contain an embedded table with
per country allowed channels and strength info.

For recent hardware these versions of the firmware are specially build for
linux-firmware, the firmware files directly available from Cypress rely on
a separate clm_blob file for this info.

For some unknown reason Cypress refuses to provide the standard firmware
files + clm_blob files it uses elsewhere for inclusion into linux-firmware,
instead relying on these special builds with the clm_blob info embedded.
This means that the linux-firmware firmware versions often lag behind,
but I digress.

Hans,

Historically the wifi firmware bin would contain all individual customer
board regulatory data which was selected via OTP (or nvram) at firmware
boot. This eventually became unscalable because the FW would need to be
updated for any new customer product and/or change.  Also the table used
more and more critical memory resources. Therefore, the regulatory data
was separated into a downloadable unit which allowed the FW to remain
independent and save on critical (FW) memory resources.

The tricky thing is that clm_blob contains regulatory data that is
specific to a board, not just the chip.

AFAIK all the important board specific settings like antenna gain are
in the NVRAM, not in the clm_blob and the clm_blob simply contains
per country settings. But you are the expert on this so I believe you when
you say that there may be some board specific stuff in there, but see below.

Also the regulatory rules often
require that a product not be able to be misconfigured (intentionally or
accidentally). To avoid regulatory violations for our customers and
general confusion, clm_blob files the matches the hardware should be
delivered by hardware (board) vendors.

Yet it clearly is possible to create a generic distributable clm_blob
as that currently is embedded into the linux-firmware brcmfmac firmware
builds. Why not split that out and add the generic clm_blob version to
linux-firmware ?

These generic clm_blob files could be added to linux-firmware under:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.cypress

And then the firmwares from can be relicensed under that license too:
https://community.cypress.com/docs/DOC-15932

Which is this 1 line change to the license:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/LICENCE.cypress?id=ba51e861f4444f51e7e83f778575a8146dc514d0

This will allow simply reusing the builds from the regular firmware releases
done at https://community.cypress.com/ to be added to linux-firmware
by interested parties like me. Avoiding situations like the
brcmfmac43455-sdio.bin file being _3.5_ years old which is really bad.

This will also mean less work for Cypress since now the same builds
you are already doing regularly can also be used directly in linux-firmware.

Regards,

Hans



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux