Re: [PATCH v3 3/9] Input: elan_i2c - Wait for initialization after enabling regulator supply

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] `regulator_enable_and_wait` sleeps for the specified duration while holding the WW mutexes for the regulator and all of its suppliers, degrading system concurrency.
--

--- Patch [3]: [PATCH v3 3/9] Input: elan_i2c - Wait for initialization after enabling regulator supply ---
commit 3e5bcc07a47c73771197519603fee461c8ac8685
Author: Chen-Yu Tsai <wenst@chromium.org>

Input: elan_i2c - Wait for initialization after enabling regulator supply

This commit switches the Elan trackpad driver to use the new
regulator_enable_and_wait() API. This ensures the required hardware and
firmware initialization delays are respected after the trackpad regulator
is enabled during probe and resume.

Link: https://lore.kernel.org/all/20241001093815.2481899-1-wenst@chromium.org/

> diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
> index 9f024a435dbf1..77885930bf9e6 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
[ ... ]
> @@ -1250,7 +1253,7 @@ static int elan_probe(struct i2c_client *client)
>  	if (IS_ERR(data->vcc))
>  		return dev_err_probe(dev, PTR_ERR(data->vcc), "Failed to get 'vcc' regulator\n");
>  
> -	error = regulator_enable(data->vcc);
> +	error = regulator_enable_and_wait(data->vcc, ETP_POWER_ON_DELAY_US);

[Severity: High]
Will using regulator_enable_and_wait() here cause a 110ms sleep while holding
the regulator's WW mutexes?

Looking at _regulator_enable_and_wait() in drivers/regulator/core.c, the sleep
happens while the dependent locks for the regulator and all of its suppliers
are still held:

drivers/regulator/core.c:_regulator_enable_and_wait() {
    ...
    if (wait_us) {
        ktime_t end = ktime_add_us(rdev->last_on, wait_us);
        s64 remaining = ktime_us_delta(end, ktime_get_boottime());

        if (remaining > 0)
            fsleep(remaining);
    }
    ...
}

Could this serialize all operations on the shared PMIC/supply during probe
and resume? 

If multiple consumers share a parent supply, wouldn't they block on the
parent's mutex and execute sequentially, potentially causing boot and resume
time regressions?

[ ... ]

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