From: sashiko-bot@kernel.org
To: "Chen-Yu Tsai" <wenst@chromium.org>
Cc: dmitry.torokhov@gmail.com, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org,
linux-input@vger.kernel.org
Subject: Re: [PATCH v5 6/7] arm64: dts: mediatek: mt8173-elm-hana: Unmark trackpad supply as always-on
Date: Tue, 25 Aug 2026 04:50:17 +0000 [thread overview]
Message-ID: <20260825045017.DE0E81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260825041628.988369-7-wenst@chromium.org>
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 <wenst@chromium.org>
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.
> 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
next prev parent reply other threads:[~2026-08-25 4:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 4:16 [PATCH v5 0/7] arm64: mediatek: Chromebook trackpad supply fixes Chen-Yu Tsai
2026-08-25 4:16 ` [PATCH v5 1/7] regulator: core: Add "enable and wait" functions Chen-Yu Tsai
2026-08-25 4:47 ` sashiko-bot
2026-08-25 7:44 ` Chen-Yu Tsai
2026-08-25 4:16 ` [PATCH v5 2/7] Input: elan_i2c - Wait for initialization after enabling regulator supply Chen-Yu Tsai
2026-08-25 4:16 ` [PATCH v5 3/7] HID: i2c-hid-of: skip post-power-on delay if powered on sufficiently long Chen-Yu Tsai
2026-08-25 4:48 ` sashiko-bot
2026-08-25 4:16 ` [PATCH v5 4/7] i2c: of-prober: " Chen-Yu Tsai
2026-08-25 4:16 ` [PATCH v5 5/7] i2c: of-prober: Defer regulator_disable() on successful probe in simple helper Chen-Yu Tsai
2026-08-25 4:48 ` sashiko-bot
2026-08-25 4:16 ` [PATCH v5 6/7] arm64: dts: mediatek: mt8173-elm-hana: Unmark trackpad supply as always-on Chen-Yu Tsai
2026-08-25 4:50 ` sashiko-bot [this message]
2026-08-25 4:16 ` [PATCH v5 7/7] arm64: dts: mediatek: mt8192-asurada-spherion: Add Synaptics trackpad's supply Chen-Yu Tsai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260825045017.DE0E81F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wenst@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox