Subject: Re: [PATCH] brcmfmac: Use request_firmware_direct for the clm_blob
To:     Hans de Goede <hdegoede@redhat.com>,
        Franky Lin <franky.lin@broadcom.com>,
        Hante Meuleman <hante.meuleman@broadcom.com>,
        Kalle Valo <kvalo@codeaurora.org>,
        Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
        Wright Feng <wright.feng@cypress.com>
Cc:     linux-wireless@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com
References: <20190107113401.6824-1-hdegoede@redhat.com>
From:   Arend Van Spriel <arend.vanspriel@broadcom.com>
Message-ID: <d6dafb19-4e88-c2c7-9547-2ebd5b4bec2e@broadcom.com>
Date:   Mon, 7 Jan 2019 12:58:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20190107113401.6824-1-hdegoede@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 1/7/2019 12:34 PM, Hans de Goede wrote:
> The linux-firmware brcmfmac firmware files contain an embedded table with
> per country allowed channels and strength info.
> 
> These versions of the firmware are specially build for linux-firmware,
> the firmware files directly available from Broadcom / Cypress rely on
> a separate clm_blob file for this info.

Hi Hans,

It is a bit more subtle than how you put it here. It is more of an 
historical thing. The table used to be embedded in firmware only. Much 
later the clm_blob loading functionality was added so customers could 
get an updated blob file while using the same firmware. In our router 
business we still provide firmwares with embedded table. Cypress decided 
to move to a model in which the firmware contains a null table and needs 
clm_blob to get things going.

> For some unknown reason Broadcom / Cypress refuse 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.

Most of them are not special builds and provided to AOSP as well.

> 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" and we will get a slow
> fallback to the userspace firmware loading mechanism.
> 
> This commit fixes both almost any brcmfmac device logging the warning
> (leaving the brcmfmac info message in pace), as well as the slow and

'pace' should probably be 'place' here.

> unnecesary fallback by switching to request_firmware_direct for
> the clm_blob.

As Kalle mentioned it is probably better to use the 'nowarn' api.

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)