firmware(9): extend firmware_get () by a "no warn" flag.
ClosedPublic
Actions

Authored by bz on Nov 29 2020, 6:32 PM.

Details

Reviewers

markj
gallatin
adrian
manu

Group Reviewers

manpages
network

Commits

rGb760436e1381: firmware(9): extend firmware_get() by a "no warn" flag.
rG6f65b505468a: firmware(9): extend firmware_get() by a "no warn" flag.

Summary

With the upcoming usage from LinuxKPI but also from drivers
ported natively we are seeing more probing of various
firmware (names).

Add the ability to firmware(9) to silence the
"firmware image loading/registering errors" by adding a new
firmware_get_flags() functions extending firmware_get() and
taking a flags argument as does firmware_put() already does.

Requested by: zeising (for future LinuxKPI/DRM)
Sponsored by: The FreeBSD Foundation
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")

Test Plan

And newer ath10k uses firmware_request_nowarn() and so does iwlwifi for the yoyo image.
We are not longer bothering our users with those if they fail to load.
Tested with upcoming LinuxKPI changes to be uploaded separately later.

For DRM this depends on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251415 .

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 35108

Event Timeline

bz created this revision.Nov 29 2020, 6:32 PM

Herald added a reviewer: manpages. · View Herald TranscriptNov 29 2020, 6:32 PM

Herald added a subscriber: imp. · View Herald Transcript

bz requested review of this revision.Nov 29 2020, 6:32 PM

Harbormaster completed remote builds in B35108: Diff 80124.Nov 29 2020, 6:32 PM

Add reminder for .Dd update on day of commit.

man/man9/firmware.9
26	Update accordingly on date of commit.

bz retitled this revision from firmware(9): extend by a "no warn" flag. to firmware(9): extend firmware_get () by a "no warn" flag..Nov 29 2020, 6:33 PM

I don't understand the need for DRM. We always want the firmware to be loaded (at the warn to be printed if it isn't found). Care to explain what Niclas requested ?
I also don't understand why you say it depends on PR251415 for DRM.

In D27413#612457, @manu wrote:

I don't understand the need for DRM. We always want the firmware to be loaded (at the warn to be printed if it isn't found). Care to explain what Niclas requested ?
I also don't understand why you say it depends on PR251415 for DRM.

Not that we didn't discuss this in length at the call on Oct 5th, some of it also is in here: https://github.com/FreeBSDDesktop/kms-firmware/pull/13#issuecomment-701577950

You'll probably understand better in a few minutes once the LinuxKPI change is up again as well. The problem is many-fold. The two more important once are: (a) linux has a "nowarn" version these days and some drivers actively probe for various firmware images or versions of it, and (b) we need to map firmware names to firmware images and ko file names so that auto-loading works properly in all cases; however you cannot 1:1 map most linux firmware paths for a FreeBSD .ko name or image name, hence (I believe the current DRM version as well) does try multiple mappings. The linux_firmware will have 4 initially (as that's most of what I found). If you hit the 4th mapping you'll get up-to 3 errors before success from firmware(9) when all you want is one final word again (that is taken care of in linuxkpi). If you really need to debug all mappings you can turn bootverbose on and also see firmware(9) tries.

The reason of the PR is if you'd want to switch and test with DRM and is that you want firmware to be built that autoloading works by firmware(9) which has not been the case in the past.

bz added a child revision: D27414: linuxkpi: add firmware loading support.Nov 29 2020, 10:17 PM

markj added inline comments.Nov 30 2020, 8:47 PM

kern/subr_firmware.c
270	So this error occurs because the driver probed for a firmware file, the linker found a KLD with a matching module or file name, but the KLD does not register a firmware image with the same name when loaded. Isn't that a packaging problem? IOW, isn't it something we should warn about even if the driver is probing for non-existent firmware files?

I'll get @markj's request in. Anything else as I'd like to commit it the next days (once I have all my workspaces and branches over to main).

kern/subr_firmware.c
270	I think I agree with you on this one after some thought. I'll change it.

Update reveting the check @markj pointed out.
Also updating date of man page for tomorrow.

Harbormaster completed remote builds in B36211: Diff 82284.Jan 14 2021, 7:07 PM

Anyone any last comments; I'd love to commit this before Monday.

markj added inline comments.Jan 25 2021, 2:04 PM

share/man/man9/firmware.9
153 ↗	(On Diff #82284)	s/registering/registration/
sys/kern/subr_firmware.c
321 ↗	(On Diff #82284)	Do you have to PHOLD across this sleep? If the kernel stack is swapped out, the thread accessing fwli can trigger a page fault otherwise. The likelihood of this happening is very low.