Re: [PATCH v3] arm64: dts: qcom: arduino-monza: add WLAN enable and rfkill GPIO

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Hardware backpowering flaw during system suspend due to uncoordinated W_DISABLE# GPIO and M.2 power supply.
- [Medium] Missing `pinctrl` definitions for newly added GPIOs.
- [Low] Devicetree schema violation for the fixed regulator node name.
--

commit ea2590eabdbe9514777a7849913aa724f8e8c30b
Author: Qian Zhang <qian.zhang@oss.qualcomm.com>

arm64: dts: qcom: arduino-monza: add WLAN enable and rfkill GPIO

This patch adds support for the QCNFA765 M.2 PCIe WLAN module by modeling
GPIO56 as a fixed regulator for wlan_en, and GPIO54 as an rfkill-gpio node.
The regulator is linked to the PCIe node to provide power sequencing.

> diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> index ca14f0ea4dae6..e0ffe87bba90c 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> @@ -153,6 +153,25 @@ vreg_nvme: regulator-3p3-m2 {
[ ... ]
> +	rfkill-wlan {
> +		compatible = "rfkill-gpio";
> +		label = "wlan";
> +		radio-type = "wlan";
> +		shutdown-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;

If the bootloader leaves the pin in an alternate function or undefined state,
the kernel might fail to control the RF kill state reliably.

Does this node require pinctrl properties to ensure GPIO 54 is muxed correctly
and has the appropriate bias and drive strength?

Additionally, the PCIe controller's vddpe-3v3-supply is disabled by the
pcie-qcom driver during system suspend, dropping power to the M.2 slot.
However, the rfkill-gpio driver lacks PM suspend/resume callbacks.

If the radio is unblocked, the SoC will continue driving GPIO 54 HIGH during
suspend while the M.2 module is unpowered.

Could this inject a logic HIGH into the unpowered module, causing current
leakage that prevents deep sleep states or damages the hardware?

Would it be better to synchronize the power sequence to safely deassert the
W_DISABLE# pin before dropping power, perhaps using the pwrseq-pci framework?

> +	};
> +
> +	wlan_reg_3v3: wlan-3v3-regulator {

This isn't a bug, but the node name wlan-3v3-regulator appears to violate the
fixed-regulator device tree schema.

According to Documentation/devicetree/bindings/regulator/fixed-regulator.yaml,
fixed regulator node names should match the pattern
^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$.

Should this be renamed to something like regulator-wlan-3v3?

> +		compatible = "regulator-fixed";
> +		regulator-name = "wlan_en";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vdc_3v3>;
> +		gpio = <&tlmm 56 GPIO_ACTIVE_HIGH>;

Similar to the rfkill node, does this regulator need a pinctrl reference to
configure GPIO 56 properly?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511-linux-next-v3-1-3e22737e71eb@oss.qualcomm.com?part=1