Thread (13 messages) 13 messages, 2 authors, 2026-08-25

Re: [PATCH v5 6/7] arm64: dts: mediatek: mt8173-elm-hana: Unmark trackpad supply as always-on

From: sashiko-bot@kernel.org
Date: 2026-08-25 04:50:18
Also in: linux-input

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing `regulator-always-on` breaks trackpad detection on Hana boards because the I2C component prober configuration hardcodes a 0ms post-power-on delay.
--
--- Patch [6]: [PATCH v5 6/7] arm64: dts: mediatek: mt8173-elm-hana: Unmark trackpad supply as always-on ---
commit 6318d2b884a1dcd37dded2350e385637ee0e9028
Author: Chen-Yu Tsai [off-list ref]

arm64: dts: mediatek: mt8173-elm-hana: Unmark trackpad supply as always-on

Up until now, the MT8173 elm/hana device tree has set the dedicated
regulator supplying the trackpad as always-on. This commit removes the
regulator-always-on property and adds the correct post-power-on-delay-ms.
quoted hunk ↗ jump to hunk
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index a0573bc359fb6..6b9f47f515c72 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -1093,7 +1093,6 @@ mt6397_vgp6_reg: ldo_vgp6 {
 				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-enable-ramp-delay = <218>;
-				regulator-always-on;
[Severity: High]
Does removing regulator-always-on here break trackpad detection on Hana boards?

When the I2C component prober runs at boot on Hana boards to determine which
trackpad is present, it uses the delay configured in its own array:

drivers/platform/chrome/chromeos_of_hw_prober.c:chromeos_i2c_probe_hana_trackpad
	/*
	 * ELAN trackpad needs 2 ms for H/W init and 100 ms for F/W init.
	 * Synaptics trackpad needs 100 ms.
	 * However, the regulator is set to "always-on", presumably to
	 * avoid this delay. The ELAN driver is also missing delays.
	 */
	.post_power_on_delay_ms = 0,

The prober passes this 0ms delay to regulator_enable_and_wait():

drivers/i2c/i2c-core-of-prober.c:i2c_of_probe_simple_enable_regulator() {
	...
	ret = regulator_enable_and_wait(ctx->supply,
					ctx->opts->post_power_on_delay_ms * USEC_PER_MSEC);
	...
}

Since 0ms is requested, it won't wait before performing the I2C read. Will this
cause the trackpad to fail probing since the regulator is no longer always-on
and the trackpad needs 100ms to boot up and respond? 

Does the prober's post_power_on_delay_ms need to be updated to 100 to match
this change?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825041628.988369-1-wenst@chromium.org?part=6
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help