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-next>] [day] [month] [year] [list]
Message-ID: <CACna6rxOGo0e9U7eXpUgnnBuxL+x1B0JBf9ZBq2WPbaBE=YZ-g@mail.gmail.com>
Date:   Sat, 10 Dec 2016 16:54:41 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     Ming Lei <ming.lei@...onical.com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:     "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        brcm80211 development <brcm80211-dev-list@...adcom.com>
Subject: Could we have request_firmware_nowait with FW_OPT_NO_WARN?

Hi,

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
(which is harmless if getting platform NVRAM succeeds). This error is
quite confusing for users. They think something went wrong, they
expect problems & they report it back to us. Obviously I don't want
ugly hacks like:
pr_info("Got platform NVRAM, ignore above error\n");

So it would be nice to have version of request_firmware_nowait with
FW_OPT_NO_WARN. If requesting firmware NVRAM fails *and* getting
platform NVRAM fails, then I could to print error on my own.
Does it make sense? Can you see a point of my request?

Do you have any suggestion for this? If and how I could proceed with
implementation?

request_firmware_nowait already has "bool uevent" argument, I don't
want it to have argument per every available option. I was thinking
about moving FW_OPT_* defines to the include/linux/firmware.h but I'm
not sure if it's OK as they depend on:
CONFIG_FW_LOADER_USER_HELPER
and
CONFIG_FW_LOADER_USER_HELPER_FALLBACK
With defines placed in firmware.h I could replace "bool uevent" with
"unsigned int opt_flags".
Does it sound like a good plan? Or do you have any better idea?

-- 
Rafał

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ