linux-kernel - [RFC 0/1] Loading optional firmware

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]

Date:   Fri,  9 Mar 2018 17:12:42 -0500
From:   Andres Rodriguez <andresx7@...il.com>
To:     linux-kernel@...r.kernel.org
Cc:     andresx7@...il.com, gregkh@...uxfoundation.org, mcgrof@...nel.org
Subject: [RFC 0/1] Loading optional firmware

Hi Everyone,

Wanted to inquire your opinions about the following matter.

We are experiencing some end user confusion regarding the following messages
being printed to dmesg:

[    0.571324] amdgpu 0000:01:00.0: Direct firmware load for amdgpu/polaris10_pfp_2.bin failed with error -2
[    0.571338] amdgpu 0000:01:00.0: Direct firmware load for amdgpu/polaris10_me_2.bin failed with error -2
[    0.571348] amdgpu 0000:01:00.0: Direct firmware load for amdgpu/polaris10_ce_2.bin failed with error -2
[    0.571366] amdgpu 0000:01:00.0: Direct firmware load for amdgpu/polaris10_mec_2.bin failed with error -2
[    0.571404] amdgpu 0000:01:00.0: Direct firmware load for amdgpu/polaris10_mec2_2.bin failed with error -2

These firmware blobs are optional. If they aren't available, the graphics card
can still function normally. But having these messages causes the user to think
their current problems are related to missing firmware.

It would be great if we could have a mechanism that enabled us to load a
firmware blob without any dmesg spew in case of file not found errors.Currently
request_firmware_direct() implements this functionality, but as a drawback it
forfeits the usermodehelper fallback path.

As part of this series, there is a small patch to enable
request_firmware_optional(), which has the same logging behaviour as
request_firmware_direct(), but will maintain the usermodehelper fallback.

Let me know if you find this change suitable, or if you would prefer a
different strategy to tackle this issue.

Andres Rodriguez (1):
  firmware: add a function to load optional firmware

 drivers/base/firmware_class.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

-- 
2.14.1