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

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

[Vitaliy Sochnev]

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.

request_firmware_direct() 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 it was meant to.

Measured on a Nokia XG-040G-MD with FW_LOADER_USER_HELPER=y and
FW_LOADER_USER_HELPER_FALLBACK=y, on two images from the same tree
differing only by this patch: without it the probe fails with
-ETIMEDOUT after 64.5s and the NPU stays unbound, with it the NPU
reports its firmware version at 3.7s. The fallback is compiled in and
forced in both cases; the patch does not disable it, it only keeps the
driver from falling into it.

Fixes: 23290c7bc190 ("net: airoha: Introduce Airoha NPU support")
Cc: stable@vger.kernel.org
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
---
 drivers/net/ethernet/airoha/airoha_npu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
index b679bed95..ca33e615a 100644
--- a/drivers/net/ethernet/airoha/airoha_npu.c
+++ b/drivers/net/ethernet/airoha/airoha_npu.c
@@ -202,7 +202,7 @@ static int airoha_npu_load_firmware(struct device *dev, void __iomem *addr,
 	const struct firmware *fw;
 	int ret;
 
-	ret = request_firmware(&fw, fw_name, dev);
+	ret = request_firmware_direct(&fw, fw_name, dev);
 	if (ret)
 		return ret == -ENOENT ? -EPROBE_DEFER : ret;
 
-- 
2.55.0

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

[Vitaliy Sochnev]

On Fri,  7 Aug 2026 03:41:08 +0100, Vitaliy Sochnev wrote:
> request_firmware_direct() 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 it was meant to.

Prior art I was not aware of when I sent this. Ziyang Huang described the
same failure and proposed the same fix for OpenWrt's copy of the driver in
March 2026:

  https://github.com/openwrt/openwrt/pull/22697

That one predates the refactor which folded the two request_firmware()
call sites into airoha_npu_load_firmware(), so it changes two lines rather
than one, and it was never sent here. The reasoning matches what I arrived
at independently, down to LEDS_LP55XX_COMMON being what selects the symbol
back on.

Recording it here rather than leaving it to be found later. If you would
like it in the commit message, I will send a v2 with a Link: tag.

Thanks,
Vitaliy

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

[Paolo Abeni]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
--- Patch [1]: [PATCH net] net: airoha: npu: load the firmware without the sysfs fallback ---
commit 1732abc5f78412a3a794eba72e4e0fbf37cf4fa7
Author: Vitaliy Sochnev <sochnev.v.74@gmail.com>

net: airoha: npu: load the firmware without the sysfs fallback

This switches airoha_npu_load_firmware() from request_firmware() to
request_firmware_direct() so that a missing firmware file is always
reported as -ENOENT and mapped to -EPROBE_DEFER, instead of running into
the sysfs/usermode-helper fallback and returning -ETIMEDOUT after the
loading timeout.

> diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
> index b679bed952de3..ca33e615a3f09 100644
> --- a/drivers/net/ethernet/airoha/airoha_npu.c
> +++ b/drivers/net/ethernet/airoha/airoha_npu.c
> @@ -202,7 +202,7 @@ static int airoha_npu_load_firmware(struct device *dev, void __iomem *addr,
>  	const struct firmware *fw;
>  	int ret;
>  
> -	ret = request_firmware(&fw, fw_name, dev);
> +	ret = request_firmware_direct(&fw, fw_name, dev);

[Severity: Low]
[Finding: main-1-0]
[Sources: opus-5]
Does this also drop the only message that names the firmware file when it
is genuinely absent or mis-pathed?

request_firmware_direct() passes FW_OPT_NO_WARN along with
FW_OPT_NOFALLBACK_SYSFS in drivers/base/firmware_loader/main.c:

	ret = _request_firmware(firmware_p, name, device, NULL, 0, 0,
				FW_OPT_UEVENT | FW_OPT_NO_WARN |
				FW_OPT_NOFALLBACK_SYSFS);

and _request_firmware() gates the file-naming warning on that flag:

		if (ret) {
			if (!(opt_flags & FW_OPT_NO_WARN))
				dev_warn(device,
					 "Direct firmware load for %s failed with error %d\n",
					 name, ret);

Inside fw_get_filesystem_firmware() the per-path -ENOENT report is only a
dev_dbg(), so nothing at default level mentions
airoha/en7581_npu_rv32.bin any more.

The driver side does not make up for it either: airoha_npu_probe() reports
through dev_err_probe(dev, err, "failed to run npu firmware\n"), and
dev_err_probe() logs at debug level for -EPROBE_DEFER, so a permanently
missing file leaves the device unbound with no default-level diagnostic
naming the file.

With CONFIG_MODULES=y the deferred probe timeout still emits one
"deferred probe pending: ... failed to run npu firmware" from
deferred_probe_timeout_work_func(), but that message does not name the
firmware file, and with driver_deferred_probe_timeout == 0 (the default
when !MODULES, or with deferred_probe_timeout=0 on the command line) even
that is absent.

Also worth noting: the kernel-doc for request_firmware_direct() scopes it
to "optional firmwares, which aren't always present", while this firmware
is mandatory for the probe to succeed. Would it be worth mentioning the
lost warning in the changelog, given the Cc: stable tag?

[Severity: Medium]
[Finding: main-1-1]
[Sources: opus-5]
Can this permanently break systems where the NPU firmware is only
delivered through the usermode helper?

fw_run_sysfs_fallback() bails out unconditionally on the flag that
request_firmware_direct() sets, in
drivers/base/firmware_loader/fallback.c:

	if ((opt_flags & FW_OPT_NOFALLBACK_SYSFS))
		return false;

So for this driver's only firmware request the helper delivery path is
gone for every invocation, not just for the boot-before-rootfs case the
change targets. If the file is not in the filesystem,
fw_get_filesystem_firmware() returns its initial -ENOENT,
airoha_npu_load_firmware() turns that into -EPROBE_DEFER, and
airoha_npu_probe() -> airoha_npu_run_firmware() ->
airoha_npu_load_firmware() re-defers forever, since the driver has no
other firmware source.

The configuration in question is exactly the one the changelog describes,
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y or force_sysfs_fallback armed,
with a helper that answers through the sysfs loading interface.

The changelog says:

  "The fallback is compiled in and forced in both cases; the patch does
   not disable it, it only keeps the driver from falling into it."

For this driver the helper path is disabled outright, including where it
is the only way the firmware arrives. Could that trade-off be spelled out
in the changelog, since the patch carries Cc: stable?
-- 
This is an AI-generated review.

Re: [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