Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

[Luis R. Rodriguez]

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@xxxxxxxxxxxx> wrote:
> > On 12-12-2016 9:32, RafaÅ MiÅecki wrote:
> >> On 12 December 2016 at 09:12, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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.

  Luis