Re: [PATCH v3 7/7] Bluetooth: qca: Set NVMEM BD address quirks when address is invalid

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Silently ignoring -EPROBE_DEFER when fetching the NVMEM BD address leads to a boot-time race condition.
--

commit 11d2d539f650246c72131a488fa018ce70494c2f
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

Bluetooth: qca: Set NVMEM BD address quirks when address is invalid

This patch adds NVMEM cell descriptions for the BD address in the device
tree and updates the QCA Bluetooth driver to set NVMEM quirks when an
invalid default address is detected, allowing the core to fetch it.

[ ... ]
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index dda76365726f0..df33eacfd29fa 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -721,8 +721,11 @@ static int qca_check_bdaddr(struct hci_dev *hdev, const struct qca_fw_config *co
>  	}
>  
>  	bda = (struct hci_rp_read_bd_addr *)skb->data;
> -	if (!bacmp(&bda->bdaddr, &config->bdaddr))
> +	if (!bacmp(&bda->bdaddr, &config->bdaddr)) {
>  		hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
> +		hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM);

[Severity: High]
Does setting this quirk silently ignore deferred probes and leave the
device unconfigured?

By setting HCI_QUIRK_USE_BDADDR_NVMEM, the NVMEM lookup is deferred to
the asynchronous power-on workqueue.

If the NVMEM provider hasn't registered the cell yet,
hci_dev_get_bd_addr_from_nvmem() returns -EPROBE_DEFER. Looking at the
core code, the return value is entirely ignored:

net/bluetooth/hci_sync.c:hci_dev_setup_sync() {
        ...
        if (hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM) &&
            !bacmp(&hdev->public_addr, BDADDR_ANY))
                hci_dev_get_bd_addr_from_nvmem(hdev);
        ...
}

Because this happens asynchronously instead of in qca_serdev_probe(),
the driver core cannot properly defer the probe.

While fw_devlink is present, partition scanning and NVMEM cell
registration for block partitions (like the mmc-card supplier
added in the dts changes) happen asynchronously after the block
driver binds.

Will this cause the Bluetooth driver to randomly fail initialization if
it probes before the NVMEM cell is fully registered?

> +		hci_set_quirk(hdev, HCI_QUIRK_BDADDR_NVMEM_BE);
> +	}
>  
>  	kfree_skb(skb);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-block-as-nvmem-v3-0-82681f50aa35@oss.qualcomm.com?part=7