Re: [PATCH v9 10/10] arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unhandled -EPROBE_DEFER during async NVMEM lookup causes fallback to random MAC/BD addresses
--

--- Patch [10]: [PATCH v9 10/10] arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses ---
commit a5efed902165c2b53cfd4d1ec5c5c615cc4e9ffa
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>
Date:   Thu Jul 30 16:00:40 2026 +0000

    arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses

This commit configures the Arduino Uno-Q device tree to expose factory-provisioned
WiFi and Bluetooth addresses from the eMMC boot1 partition. It updates the
bluetooth and wifi nodes to retrieve their addresses from these newly mapped
NVMEM cells.

> diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> index bf088fa9807f0..38839b8a361e7 100644
> --- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> +++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts

[ ... ]

> @@ -512,6 +538,9 @@ bluetooth {
>  		vddch0-supply = <&pm4125_l22>;
>  		enable-gpios = <&tlmm 87 GPIO_ACTIVE_HIGH>;
>  		max-speed = <3000000>;
> +
> +		nvmem-cells = <&bd_addr 0>;
> +		nvmem-cell-names = "local-bd-address";

[Severity: High]
This is a pre-existing issue, but could this cause the Bluetooth
controller to fall back to a random BD address?

The NVMEM provider here is an eMMC block device, which registers
asynchronously during mmc_rescan. This means the NVMEM provider might
not be ready when the Bluetooth driver looks it up, causing the lookup
to return -EPROBE_DEFER.

Because the Bluetooth HCI core performs this lookup asynchronously
during firmware initialization:

net/bluetooth/hci_sync.c:hci_dev_setup_sync() {
        ...
        hci_dev_get_bd_addr_from_nvmem(hdev);
        ...
}

the return value is ignored. Since the async context cannot bubble up
-EPROBE_DEFER to the driver core, will this silently fail and use
a default or random address instead of waiting for the eMMC provider?

>  	};
>  };
>  
> @@ -557,6 +586,9 @@ &wifi {
>  	qcom,ath10k-calibration-variant = "ArduinoImola";
>  	firmware-name = "qcm2290";
>  
> +	nvmem-cells = <&wifi_mac_addr 0>;
> +	nvmem-cell-names = "mac-address";

[Severity: High]
This isn't a bug introduced by this patch, but similar to the Bluetooth
node, will this cause ath10k to fall back to a random MAC address?

ath10k also performs the NVMEM lookup asynchronously during firmware
initialization:

drivers/net/wireless/ath/ath10k/core.c:ath10k_core_probe_fw() {
        ...
        device_get_mac_address(ar->dev, ar->mac_addr);
        ...
}

If the eMMC provider is not ready, this returns -EPROBE_DEFER which
is ignored in the async workqueue, preventing proper deferral.

> +
>  	status = "okay";
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-block-as-nvmem-v9-0-f72935817dbf@oss.qualcomm.com?part=10