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

[bz]

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 .

[bz]

Add reminder for .Dd update on day of commit.

man/man9/firmware.9

26 ↗

(On Diff #80124)

Update accordingly on date of commit.

[manu]

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.

[bz]

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.

[markj]

kern/subr_firmware.c

270 ↗

(On Diff #80124)

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?

[bz]

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 ↗

(On Diff #80124)

I think I agree with you on this one after some thought. I'll change it.

[bz]

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

[bz]

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

[markj]

share/man/man9/firmware.9

153

s/registering/registration/

sys/kern/subr_firmware.c

322–323

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.

[bz]

Address comments from @markj.
Bump .Dd date in man page to tomorrow.

[bz]

Thanks @markj ! Does it look good now?

sys/kern/subr_firmware.c

322–323

Good catch. I've been generous with the amount under the "hold" beyond the msleep.

[markj]

sys/kern/subr_firmware.c

322–323

Really you only need it across the msleep() call.