[PATCH v2] brcmfmac: Use firmware_request_nowarn for the clm_blob

[PATCH v2] brcmfmac: Use firmware_request_nowarn for the clm_blob

[Hans de Goede]

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.

The brcmfmac driver does support the separate clm_blob file and always
tries to load this. Currently we use request_firmware for this. This means
that on any standard install, using the standard combo of linux-kernel +
linux-firmware, we will get a warning:
"Direct firmware load for ... failed with error -2"

On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
device may have limited channels available".

This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
device logging the warning (it leaves the brcmfmac info message in place).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Use firmware_request_nowarn instead of request_firmware_direct
-Reword commit message a bit to match (and fix a typo)
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 0bb16bf574e3..e29f56888761 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -149,7 +149,7 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
 		return err;
 	}
 
-	err = request_firmware(&clm, clm_name, bus->dev);
+	err = firmware_request_nowarn(&clm, clm_name, bus->dev);
 	if (err) {
 		brcmf_info("no clm_blob available (err=%d), device may have limited channels available\n",
 			   err);
-- 
2.20.1

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

[Chi-Hsien Lin]

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. 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.

As you mentioned, this paragraph has disgressed. Please remove it from 
the commit message.

> 
> The brcmfmac driver does support the separate clm_blob file and always
> tries to load this. Currently we use request_firmware for this. This means
> that on any standard install, using the standard combo of linux-kernel +
> linux-firmware, we will get a warning:
> "Direct firmware load for ... failed with error -2"
> 
> On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
> device may have limited channels available".
> 
> This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
> device logging the warning (it leaves the brcmfmac info message in place).
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> -Use firmware_request_nowarn instead of request_firmware_direct
> -Reword commit message a bit to match (and fix a typo)
> ---
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 0bb16bf574e3..e29f56888761 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -149,7 +149,7 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
>   		return err;
>   	}
>   
> -	err = request_firmware(&clm, clm_name, bus->dev);
> +	err = firmware_request_nowarn(&clm, clm_name, bus->dev);
>   	if (err) {
>   		brcmf_info("no clm_blob available (err=%d), device may have limited channels available\n",
>   			   err);
> 

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

[Hans de Goede]

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

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

[Kalle Valo]

Hans de Goede <hdegoede@redhat.com> 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.
> 
> The brcmfmac driver does support the separate clm_blob file and always
> tries to load this. Currently we use request_firmware for this. This means
> that on any standard install, using the standard combo of linux-kernel +
> linux-firmware, we will get a warning:
> "Direct firmware load for ... failed with error -2"
> 
> On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
> device may have limited channels available".
> 
> This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
> device logging the warning (it leaves the brcmfmac info message in place).
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Patch applied to wireless-drivers-next.git, thanks.

4ad0be160544 brcmfmac: Use firmware_request_nowarn for the clm_blob

-- 
https://patchwork.kernel.org/patch/10750585/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches