Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752198AbcLLLtG (ORCPT ); Mon, 12 Dec 2016 06:49:06 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:34176 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbcLLLtE (ORCPT ); Mon, 12 Dec 2016 06:49:04 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 965F46029D Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=kvalo@codeaurora.org From: Kalle Valo To: =?utf-8?Q?Rafa=C5=82_Mi=C5=82ecki?= Cc: Johannes Berg , Ming Lei , "Luis R. Rodriguez" , Linux Kernel Mailing List , "linux-wireless\@vger.kernel.org" , brcm80211 development Subject: Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? References: <1481530339.4067.1.camel@sipsolutions.net> Date: Mon, 12 Dec 2016 13:48:58 +0200 In-Reply-To: (=?utf-8?Q?=22Rafa=C5=82_Mi=C5=82ecki=22's?= message of "Mon, 12 Dec 2016 09:32:26 +0100") Message-ID: <87y3zll651.fsf@purkki.adurom.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uBCBnD3l026033 Content-Length: 1142 Lines: 28 Rafał Miłecki writes: > On 12 December 2016 at 09:12, Johannes Berg wrote: >> On Sat, 2016-12-10 at 16:54 +0100, Rafał Miłecki wrote: >>> In brcmfmac we use request_firmware_nowait and if fetching firmware >>> with NVRAM variables fails then we try to fallback to the platform >>> one (see brcmf_fw_request_code_done & brcmf_fw_request_nvram_done). >>> >>> Some problem for us is that on devices with platform NVRAM we get >>> this error: >>> Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2 >> >> This also happens with iwlwifi, because it requests multiple firmware >> versions starting at the most recent supported one (which is often not >> released at the same time). > > Good to know it may help others as well! We have the same problem also on ath10k :) And it's confusing users a lot, especially as we also load calibration file and other files. So yes, something like this is very much needed. But in ath10k we use request_firmware() instead request_firmware_nowait(). So I would appreciate if you could add the support to both variants. -- Kalle Valo