linux_firmware: remove `enoentok` logic in `*firmware_request(..)`

[ngie]

Summary

Prior to this change, in the event that a firmware module could not be
loaded, the linux_firmware driver would return a partially initialized
structure with uninitialized/zeroed out values for certain fields. Linux
does not do this, however, so some drivers that use
request_firmware_nowait expecting Linux behavior, like if_bcrmfmac,
would crash trying to dereference a NULL pointer.

This doesn't address the load/unload situation completely as the driver
remains loaded after the "firmware crashes", but it makes a completely
unusable situation (a kernel panic) into a slightly more usable situation
(driver does not unload).

MFC after: 2 weeks

Test Plan

• This allowed my 2016 MacBook Pro to boot successfully whereas it was panicking before.
• Another Mac I have access to continued to function in the same manner after this change.

[ngie]

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

127

Part of the reason why I switched this from a free(..) to linuxkpi_release_firmware(..) is that it helps tear down more linuxkpi state than just free(9) does, resulting in less potential leaked resources.
I should note this in the commit message.

[bz]

The fact that there was a different behaviour with the extra bool means there was a reason for this.
We cannot unconditionally clear this and change behaviour as we still support Linux 6.1-lts drm-kmod and others.
This will need more careful investigation.

For the moment you are compiling a driver which is disabled and not yet supported so I'd say you are on your own until this gets sorted properly.

[ngie]

In D58451#1340983, @bz wrote:

The fact that there was a different behaviour with the extra bool means there was a reason for this.
We cannot unconditionally clear this and change behaviour as we still support Linux 6.1-lts drm-kmod and others.
This will need more careful investigation.

I understand and agree. This change has the potential to disrupt other areas which could cause grief with other drivers/deployments.

For the moment you are compiling a driver which is disabled and not yet supported so I'd say you are on your own until this gets sorted properly.

Yeah, I get that, but there is an issue with the KPI as it exists that it differs behaviorally from Linux: the fact that the block exists at all with brcm is why the driver panics on attach on :main with a NULL pointer dereference.

If the behavior differs, it will probably need to be a chicken switch of sorts where Linux <version1> follows one path and Linux <version2> follows another.