Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752970AbcLLOQe (ORCPT ); Mon, 12 Dec 2016 09:16:34 -0500 Received: from mail-oi0-f67.google.com ([209.85.218.67]:35139 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751640AbcLLOQc (ORCPT ); Mon, 12 Dec 2016 09:16:32 -0500 MIME-Version: 1.0 In-Reply-To: <20161212140739.GB1402@wotan.suse.de> References: <1481530339.4067.1.camel@sipsolutions.net> <815a15b6-f22d-8c45-f76c-2c756f159366@broadcom.com> <20161212140739.GB1402@wotan.suse.de> From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Date: Mon, 12 Dec 2016 15:16:31 +0100 Message-ID: Subject: Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? To: "Luis R. Rodriguez" Cc: Arend Van Spriel , Johannes Berg , Ming Lei , Linux Kernel Mailing List , "linux-wireless@vger.kernel.org" , brcm80211 development 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 uBCEGdtv008944 Content-Length: 2743 Lines: 60 On 12 December 2016 at 15:07, Luis R. Rodriguez wrote: > On Mon, Dec 12, 2016 at 10:53:38AM +0100, Rafał Miłecki wrote: >> On 12 December 2016 at 10:26, Arend Van Spriel >> wrote: >> > On 12-12-2016 9:32, Rafał Miłecki wrote: >> >> 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! >> >> >> >> >> >>> So yeah, this would be really useful - why don't you just make a patch >> >>> with some kind of flags, whether it's FW_OPT_* or new flags? >> >> >> >> OK! If noone will come with any special comments/ideas soon, I'll >> >> propose a patch for using some flags. >> >> >> >> FWIW, meanwhile I submitted >> >> [PATCH V2] firmware: simplify defining and handling FW_OPT_FALLBACK >> >> https://patchwork.kernel.org/patch/9469875/ >> > >> > Similar thread couple of months ago [1] >> > >> > (...) >> > >> > [1] http://lists.infradead.org/pipermail/ath10k/2016-July/thread.html#8026 >> >> Oh, now I see it's a bit messy topic and not clearly maintained class. >> It seems more ppl were confused by the API. I think having many >> unrelated behavior bounded to few functions caused some of this >> confusion. Let's hope adding some flags will let us use function the >> way they were designed, I'll definitely try working on this. > > 4.9 was just released, this means the merge window opened and no functional > changes will be merged for a while. I'll revamp my new API whcih would allow > what you describe to be an add-on flag without having to extend the API with > yet another series of exported symbols just for a new option. I'll also > CC you on a documentation revamp because as you note its much needed. I started working on request_firmware_async with "unsigned int opt_flags" argument and making request_firmware_nowait an inline function just passing proper flags. Well, I guess it's always disappointing having to drop your work, but let it be... Please Cc me with your patches as well as documentation update. -- Rafał