[PATCH net] net: airoha: npu: load the firmware without the sysfs fallback

[Vitaliy Sochnev]

Both findings look right, thanks - v2 addresses them in the code rather
than only in the changelog.

main-1-0, the lost warning: confirmed. request_firmware_direct() sets
FW_OPT_NO_WARN, and the driver did not compensate. airoha_npu_load_firmware()
returned the code silently and airoha_npu_probe() reported a generic
"failed to run npu firmware" through dev_err_probe(), which at
-EPROBE_DEFER only stores the string as the deferred-probe reason. So the
file name reached neither the log nor the "deferred probe pending" line.

This is not hypothetical: I hit it myself building an AN7583 image that
shipped the en7581 firmware set but not an7583_npu_rv32.bin. The pending
message named nothing, and it cost me a rebuild to work out what was
missing.

Since the regression would be introduced by this patch, and the patch
carries Cc: stable, I did not want to leave it to a follow-up that stable
might not pick up. v2 reports the failure from airoha_npu_load_firmware()
through dev_err_probe() with the file name, so it lands in the deferred
probe reason and the timeout line names it. The generic report in
airoha_npu_probe() goes, since it would overwrite that reason; of the
paths it covered, devm_ioremap_resource() reports itself and the
malformed firmware-name property now does too.

main-1-1, the usermode helper: also correct, and my wording was too
narrow. "the patch does not disable it, it only keeps the driver from
falling into it" holds for the mechanism in general but not for this
driver's requests, which lose the helper route entirely, including where
it is the only one. v2 states that as a deliberate trade-off: the -ENOENT
to -EPROBE_DEFER mapping was written to wait for a filesystem, and the
sysfs helper interface has had no in-tree consumer since udev dropped
firmware loading.

v2 shortly, as a separate thread.

Thanks,
Vitaliy