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

On Tue, Aug 11, 2026 at 07:16:59PM +0100, Vitaliy Sochnev wrote:
> airoha_npu_load_firmware() maps a missing firmware file to -EPROBE_DEFER
> so that the NPU can be brought up once the rootfs carrying /lib/firmware
> has been mounted. That mapping holds only as long as request_firmware()
> reports -ENOENT.
> 
> It does not when the sysfs fallback is in play. With
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK set, or with the fallback armed at
> runtime through /proc/sys/kernel/firmware_config/force_sysfs_fallback,
> request_firmware() hands the request to a userspace helper, waits out the
> full loading_timeout and returns -ETIMEDOUT. The -ENOENT test no longer
> matches, dev_err_probe() turns the result into a hard failure, and the
> NPU is left unbound after stalling the boot for 60 seconds:
> 
>   airoha-npu 1e900000.npu: Direct firmware load for airoha/en7581_npu_rv32.bin failed with error -2
>   airoha-npu 1e900000.npu: Falling back to sysfs fallback for: airoha/en7581_npu_rv32.bin
>   airoha-npu 1e900000.npu: error -ETIMEDOUT: failed to run npu firmware
>   airoha-npu 1e900000.npu: probe with driver airoha-npu failed with error -110
> 
> Clearing FW_LOADER_USER_HELPER in the configuration is not a dependable
> guard against this, because unrelated drivers select it. On the affected
> build the symbol was turned back on by LEDS_LP55XX_COMMON, even though
> the platform had explicitly disabled it.
> 
> Use request_firmware_direct() instead. It sets FW_OPT_NOFALLBACK_SYSFS,
> so a missing file is reported as -ENOENT whatever the firmware loader is
> configured to do, and the deferred probe path works as intended.
> 
> Two consequences are worth stating plainly.
> 
> The helper is not merely bypassed for the boot-before-rootfs case.
> fw_run_sysfs_fallback() returns early on FW_OPT_NOFALLBACK_SYSFS, so this
> driver's firmware requests can no longer be served by a usermode helper
> at all, including on a system where that is the only delivery route;
> having no second firmware source, the driver would defer forever there.
> That is 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.
> 
> request_firmware_direct() also sets FW_OPT_NO_WARN, which drops the only
> message naming the file that failed to load. Report it from the driver
> instead, so the name lands in the deferred probe reason and shows up in
> the "deferred probe pending" line emitted at
> driver_deferred_probe_timeout. The generic report in airoha_npu_probe()
> goes away with it, since it would otherwise overwrite that reason with a
> message naming nothing; of the paths it covered, devm_ioremap_resource()
> reports itself and the malformed firmware-name property now does too.
> 
> Measured on a Nokia XG-040G-MD with FW_LOADER_USER_HELPER=y and
> FW_LOADER_USER_HELPER_FALLBACK=y forced on, two images from the same
> tree differing only by this patch:
> 
>   without:  fallback at 2.477s -> -ETIMEDOUT at 64.555s -> probe failed
>             with -110, preinit at 69.6s, NPU unbound
>   with:     no fallback, NPU fw version 1456.62 at 3.665s, preinit at
>             7.6s
> 
> Fixes: 23290c7bc190 ("net: airoha: Introduce Airoha NPU support")
> Cc: [email protected]
> Signed-off-by: Vitaliy Sochnev <[email protected]>
> ---
> v2:
>  - Keep the file name in the diagnostics. request_firmware_direct() also
>    sets FW_OPT_NO_WARN, which dropped the only message naming the file;
>    report it from airoha_npu_load_firmware() through dev_err_probe() so
>    the name lands in the deferred probe reason. Drop the generic report
>    in airoha_npu_probe(), which would overwrite that reason, and give
>    the malformed firmware-name path a message of its own.
>  - Say in the changelog that the usermode helper path is disabled for
>    this driver's requests rather than merely bypassed, and why that
>    trade-off is acceptable.
>  - Both points raised in review of v1:
>    https://lore.kernel.org/netdev/[email protected]/

Reviewed-by: Simon Horman <[email protected]>