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

[Chi-Hsien Lin <Chi-Hsien.Lin@cypress.com>]

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);
>