Re: [PATCH v3] arm64: dts: qcom: shikra-iqs: add M.2 Wi-Fi and Bluetooth overlay

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] arm64: dts: qcom: unapplied shikra M.2 overlay and missing base DTB targets
- [Medium] arm64: dts: qcom: missing address/size cells and status in i2c3 overlay node
- [Medium] arm64: dts: qcom: shikra-iqs: duplicate m2_keye_3p3 supply on pcie and M.2 connector
--

commit 09177a14c1310eacd965626caf4a52cacd777f25
Author: Linghui Wu <linghui.wu@oss.qualcomm.com>

arm64: dts: qcom: shikra-iqs: add M.2 Wi-Fi and Bluetooth overlay

This patch adds a device tree overlay for M.2 Key-E Wi-Fi and Bluetooth
modules on the Qualcomm Shikra IQS EVK and disables the onboard WCN3988
Wi-Fi and Bluetooth nodes when applied.

> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 1c86e7e98f55d..799faa32e2d98 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -339,6 +339,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdx75-idp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= shikra-cqm-evk.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= shikra-cqs-evk.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= shikra-iqs-evk.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= shikra-iqs-evk-m2-wifi-bt.dtbo
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm4250-oneplus-billie2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm4450-qrd.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm6115-fxtec-pro1x.dtb

[Severity: High]
Does adding shikra-iqs-evk-m2-wifi-bt.dtbo directly to dtb-$(CONFIG_ARCH_QCOM)
without a composite -dtbs target cause a Kbuild warning and prevent the base
DTB from being compiled with symbols?

In scripts/Makefile.dtbs, Kbuild checks that every .dtbo in dtb-y is applied
to at least one base .dtb via a -dtbs rule:

scripts/Makefile.dtbs:
	applied-dtbo := $(filter %.dtbo, \
		$(call real-search, $(call multi-search, $(all-dtb), .dtb, -dtbs), .dtb, -dtbs))
	unapplied-dtbo := $(filter-out $(applied-dtbo),$(filter %.dtbo, $(dtb-y)))
	$(if $(unapplied-dtbo), $(warning .dtbo is not applied to any base: $(unapplied-dtbo)))

In addition, scripts/Makefile.dtbs only passes -@ to dtc for base DTBs listed
in a composite -dtbs rule (base-dtb-y). Without defining:

	shikra-iqs-evk-m2-wifi-bt-dtbs := shikra-iqs-evk.dtb shikra-iqs-evk-m2-wifi-bt.dtbo
	dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk-m2-wifi-bt.dtb

shikra-iqs-evk.dtb is compiled without a /__symbols__ node, so the overlay
cannot be applied to it. Furthermore, when attempting to apply this overlay
to shikra-iqs-evk.dtb, the target labels &pcie, &pcie_port0, and &tc9563
referenced below do not exist in shikra.dtsi, shikra-iqs-som.dtsi,
shikra-evk.dtsi, or shikra-iqs-evk.dts, causing fdtoverlay to fail with
FDT_ERR_NOTFOUND. Is this patch depending on unmerged base DTB changes?

> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk-m2-wifi-bt.dtso b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-m2-wifi-bt.dtso
> new file mode 100644
> index 0000000000000..985c728dd693d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-m2-wifi-bt.dtso
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2026 Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&{/} {
> +	m2_keye_3p3: regulator-m2-keye-3p3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VREG_3P3_KEYE";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&qps_gpio_expander 6 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
> +	wifi-bt-connector {
> +		compatible = "pcie-m2-e-connector";
> +
> +		vpcie3v3-supply = <&m2_keye_3p3>;
> +		w-disable1-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
> +		w-disable2-gpios = <&tlmm 60 GPIO_ACTIVE_LOW>;

[ ... ]

> +&i2c3 {
> +	qps_gpio_expander: gpio@3c {
> +		compatible = "nxp,pca9534";
> +		reg = <0x3c>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +	};
> +};

[Severity: Medium]
Should the &i2c3 fragment include #address-cells = <1>, #size-cells = <0>,
and status = "okay"?

When dtc compiles the .dtso plugin in isolation, check_reg_format() and
check_avoid_default_addr_size() in scripts/dtc/checks.c evaluate gpio@3c
against the fragment parent, which defaults to 2 address cells and 1 size
cell when #address-cells and #size-cells are omitted, emitting reg_format
and avoid_default_addr_size warnings on reg = <0x3c>.

Also, in arch/arm64/boot/dts/qcom/shikra.dtsi, i2c3 is defined with
status = "disabled" and is not enabled in the board DTS/DTSI files:

arch/arm64/boot/dts/qcom/shikra.dtsi:
	i2c3: i2c@4a8c000 {
		compatible = "qcom,geni-i2c";
		...
		status = "disabled";
	};

Without status = "okay" on &i2c3, will qps_gpio_expander and the dependent
m2_keye_3p3 regulator fail to probe?

> +
> +&pcie {
> +	iommu-map = <0x0 &apps_smmu 0x0800 0x0 0x1>,
> +		    <0x100 &apps_smmu 0x0801 0x0 0x1>;
> +	vddpe-3v3-supply = <&m2_keye_3p3>;
> +};

[Severity: Medium]
Will assigning &m2_keye_3p3 to both vddpe-3v3-supply on &pcie and
vpcie3v3-supply on wifi-bt-connector cause the PCIe host controller and
the M.2 power sequencer to contend over the 3.3 V regulator?

During qcom_pcie_probe() -> dw_pcie_host_init() -> qcom_pcie_host_init()
in drivers/pci/controller/dwc/pcie-qcom.c:

	ret = pcie->cfg->ops->init(pcie);
	if (ret)
		return ret;

	ret = qcom_pcie_phy_power_on(pcie);
	if (ret)
		goto err_deinit;

	if (!pci->suspended) {
		ret = pci_pwrctrl_create_devices(pci->dev);
		if (ret)
			goto err_disable_phy;
	}

	if (!pp->skip_pwrctrl_off) {
		ret = pci_pwrctrl_power_on_devices(pci->dev);
		if (ret)
			goto err_pwrctrl_destroy;
	}

pcie->cfg->ops->init(pcie) enables vddpe-3v3 (&m2_keye_3p3) directly before
pci_pwrctrl_create_devices() and pci_pwrctrl_power_on_devices() run. When
pci_pwrctrl_power_on_devices() returns -EPROBE_DEFER while waiting for
pci-pwrctrl-slot and pwrseq-pcie-m2 to bind, qcom_pcie_host_init() unwinds
through err_deinit and disables &m2_keye_3p3, glitching the 3.3 V rail
before re-probing. Once bound, &pcie also holds a direct enable vote on
&m2_keye_3p3 outside of pwrseq-pcie-m2. Should vddpe-3v3-supply be omitted
from &pcie so that &m2_keye_3p3 is managed solely via vpcie3v3-supply on
wifi-bt-connector?

[ ... ]

>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261020020925.3915548-1-linghui.wu@oss.qualcomm.com?part=1