linux-kernel - Re: Could we have request_firmware_nowait with FW_OPT_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 12 Dec 2016 15:16:31 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Arend Van Spriel <arend.vanspriel@...adcom.com>,
        Johannes Berg <johannes@...solutions.net>,
        Ming Lei <ming.lei@...onical.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        brcm80211 development <brcm80211-dev-list@...adcom.com>
Subject: Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

On 12 December 2016 at 15:07, Luis R. Rodriguez <mcgrof@...nel.org> 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
>> <arend.vanspriel@...adcom.com> wrote:
>> > On 12-12-2016 9:32, Rafał Miłecki wrote:
>> >> On 12 December 2016 at 09:12, Johannes Berg <johannes@...solutions.net> 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ł