Re: [PATCH v2 16/16] arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as M.2 E-key slot

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The pinctrl configuration for the W_DISABLE kill pins drives them physically HIGH before the VIO/VCC regulators are enabled, causing chip back-powering and an initial signal glitch.
--

commit c9c4e7dd87a963320b0c2bf646e1e008f5ee5638
Author: Chen-Yu Tsai <wenst@chromium.org>

arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as M.2 E-key slot

This commit models the chip-on-board WiFi/BT solution on MT8188 Geralt as
an M.2 E-key slot. It adds the PMU_EN pin controls and drops the always-on
property from the pp3300_wlan regulator to properly reflect power sequencing.

> diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> index 4cb23595d17b4..d7b5eb95ba0fe 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
[ ... ]
> @@ -193,6 +202,39 @@ adsp_dma_mem: memory@61000000 {
>  			no-map;
>  		};
>  	};
> +
> +	wifi-bt-connector {
> +		compatible = "pcie-m2-e-connector";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&m2_e_key_kill_pins>;
> +		vpcie1v8-supply = <&mt6359_vcn18_ldo_reg>;
> +		vpcie3v3-supply = <&wlan_pmu>;
> +		w-disable1-gpios = <&pio 13 GPIO_ACTIVE_LOW>;
> +		w-disable2-gpios = <&pio 14 GPIO_ACTIVE_LOW>;
[ ... ]
> @@ -999,6 +1057,14 @@ pins-bus {
>  		};
>  	};
>  
> +	m2_e_key_kill_pins: m2-e-key-kill-pins {
> +		pins-kill {
> +			pinmux = <PINMUX_GPIO13__FUNC_B_GPIO13>,
> +				 <PINMUX_GPIO14__FUNC_B_GPIO14>;
> +			output-high;

[Severity: High]
Since pp3300_wlan is no longer always-on, does this output-high configuration
cause the unpowered Wi-Fi/BT chip to be back-powered?

The device core automatically applies the default pinctrl state during
instantiation, before the power sequence driver probes and turns on the
regulators. Driving a physical HIGH voltage into the w-disable pins of an
unpowered IC can forward-bias internal ESD diodes and leak current.

Additionally, when the driver eventually probes, it will request the
w-disable pins. Since the wifi-bt-connector node defines them as
GPIO_ACTIVE_LOW, requesting a logical HIGH translates to a physical LOW.

Will this result in an unintended HIGH-to-LOW physical glitch on the
unpowered chip's w-disable lines before the regulators are finally enabled?

> +		};
> +	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=16