Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1540224
| From | Rafał Miłecki <zajec5@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? |
| Date | 2016-12-12 11:00 +0100 |
| Message-ID | <sNvyN-2HP-17@gated-at.bofh.it> (permalink) |
| References | <sMSea-47F-13@gated-at.bofh.it> <sNu02-1Wi-19@gated-at.bofh.it> <sNujn-22B-9@gated-at.bofh.it> <sNv5M-2y3-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 12 December 2016 at 10:26, Arend Van Spriel <arend.vanspriel@broadcom.com> wrote: > On 12-12-2016 9:32, Rafał Miłecki wrote: >> On 12 December 2016 at 09:12, Johannes Berg <johannes@sipsolutions.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. -- Rafał
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Could we have request_firmware_nowait with FW_OPT_NO_WARN? Rafał Miłecki <zajec5@gmail.com> - 2016-12-10 17:00 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? Johannes Berg <johannes@sipsolutions.net> - 2016-12-12 09:20 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? Rafał Miłecki <zajec5@gmail.com> - 2016-12-12 09:40 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? Arend Van Spriel <arend.vanspriel@broadcom.com> - 2016-12-12 10:30 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? Rafał Miłecki <zajec5@gmail.com> - 2016-12-12 11:00 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-12-12 15:10 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? Rafał Miłecki <zajec5@gmail.com> - 2016-12-12 15:20 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? Kalle Valo <kvalo@codeaurora.org> - 2016-12-12 12:50 +0100
Re: Could we have request_firmware_nowait with FW_OPT_NO_WARN? "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-12-12 15:20 +0100
csiph-web