linuxkpi: add firmware loading support

[bz]

Summary

Implement linux firmware KPI compat code.
This includes: request_firmware() request_firmware_nowait(),
firmware_request_nowarn(), and release_firmware().
We do not currently defer loading in the "nowait" case.

Given we will try to map requested names from natively ported
or full-linuxkpi using drivers to a firmware(9) auto-loading
format in which we can handle the .ko file and image name
we quieten firmware(9) and print success or failure (unless
the _nowarn() version was called) on the linuxkpi implementation.
At the moment we try up-to 4 different naming combinations,
with path stripped, original name, and requested name with '/'
or '.' replaced.

Sponsored by: The FreeBSD Foundation
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") (firmware(9) update)

Changes since the last version ( D26277, D26598 ): addressed kib's comments, fixed a bug when returning fw pointer in error case not being initialized to zero [as some drivers will use any results], implement the _nowarn() version needed by iwlwifi now, and ath10k(athp once switched), make use of firmware(9) NOWARN flag to quieten attempts possibly confusing users and add our own printfs (respecting the linux _nowarn() version).

Let me know in case I need to bump __FreeBSD_version.

Test Plan

Tested with 4 WiFi drivers; and DRM in an earlier version.

[manu]

sys/compat/linuxkpi/common/src/linux_firmware.c

113

Using the bsddev and device_printf would be better.

118

Same here.

138

Is it something that Linux does ? (Running the callback defered).
If yes is it something that you plan to add support to ?

[bz]

Pass dev in to the common function so we can use device_printf() as suggested by manu.
Update the comment about running the "_nowait()" context deferred.

[bz]

sys/compat/linuxkpi/common/src/linux_firmware.c

113

Done. Thanks. Good idea!

138

I currently do not plan to implement it.
None of the drivers I have seen so far and tested do require it.
I updated the comment to be more clear.

The comment is merely left that in case in 10 years someone works on a driver which needs the deferred context they can find the problem more easily. Should I come across a driver needing it, I will of course implement it.

[bz]

@manu, did we come to the conclusion last year that currently doing this all natively was not always working and we are going with this one as the next (first) step? I'd love to commit this as soon as firmware(9) changes are in and D26598 is updated and accepted, so that we don't have to update DRM ports too often.

[manu]

In D27414#629460, @bz wrote:

@manu, did we come to the conclusion last year that currently doing this all natively was not always working and we are going with this one as the next (first) step? I'd love to commit this as soon as firmware(9) changes are in and D26598 is updated and accepted, so that we don't have to update DRM ports too often.

I don't remember.
I suggest just trying main + those two reviews and drm-devel-kmod, if that works that's good, otherwise just tell me the problem.

[bz]

Changes since last:

• add request_firmware_direct() needed by DRM.

[bz]

@manu works for Intel.

I have a diff for FreeBSD_version checks for this and D26598 that can be applied to drm-kmod as well (once the FreeBSD_version is known) so that the conflicts are gone here: https://people.freebsd.org/~bz/tmp/2021-01-15-02-drm-kmod-FreeBSD_version-checks-firmware-linuxkpi-conflicts.diff

Current dummy version from testing: 000001 was for firmware and 2 was for D26598.

[bz]

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