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

On 5/12/2026 9:09 AM, [email protected] wrote:
> 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.
> --
> 
Hi,

Thank you for the review.

I will address issues 2 and 3 in v4 by adding pinctrl definitions for both
GPIOs and renaming the regulator node to follow the schema requirements.

Regarding issue 1 (the suspend/resume power sequencing concern), I will
provide detailed context about the current situation when responding to
other review comments.

Regards,
Qian

> commit ea2590eabdbe9514777a7849913aa724f8e8c30b
> Author: Qian Zhang <[email protected]>
> 
> 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?
>