Re: [PATCH v6 01/10] soc: bcm2835: Use IS_REACHABLE for function declaration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Replacing IS_ENABLED() with IS_REACHABLE() introduces silent runtime failures (such as infinite probe-deferral loops or silently failing operations) by hiding unresolved module dependencies behind inline stubs.
--

commit 4df320b82133df67fcde1204534b53b54b092612
Author: Gregor Herburger <gregor.herburger@linutronix.de>

soc: bcm2835: Use IS_REACHABLE for function declaration

This commit modifies the raspberrypi-firmware header to use IS_REACHABLE
instead of IS_ENABLED for function declarations. It aims to simplify
Kconfig dependencies for dependent drivers while avoiding linker errors
during COMPILE_TEST builds where the firmware is modular.

> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index e1f87fbfe5542..eb33838e0cd10 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -174,7 +174,7 @@ struct rpi_firmware_clk_rate_request {
>  		.id = cpu_to_le32(_id),		\
>  	}
>  
> -#if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
> +#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)

[Severity: High]
Could this change introduce silent runtime failures for dependent drivers?

When a dependent driver is compiled as built-in (=y) via COMPILE_TEST while
the firmware is compiled as a module (=m), IS_REACHABLE evaluates to false.
This causes the compiler to silently substitute hardcoded inline stubs
instead of linking against the real firmware functions.

Consequently, the build succeeds but the drivers might fundamentally fail at
runtime. For example, devm_rpi_firmware_get() returning NULL could cause a
permanent -EPROBE_DEFER loop, or rpi_firmware_property() returning -ENOSYS
might break all NVMEM reads and writes.

The previous Kconfig dependency forced dependent drivers to =m in this
scenario, guaranteeing functional runtime behavior and using linker errors
to enforce correct configurations. Does using IS_REACHABLE here mask these
module dependencies in a way that breaks the drivers at runtime?

>  int rpi_firmware_property(struct rpi_firmware *fw,
>  			  u32 tag, void *data, size_t len);
>  int rpi_firmware_property_list(struct rpi_firmware *fw,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de?part=1