lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZvvHdlD6E5bzsWwV@google.com>
Date: Tue, 1 Oct 2024 02:57:10 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Chen-Yu Tsai <wenst@...omium.org>, Mark Brown <broonie@...nel.org>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mediatek@...ts.infradead.org,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH] Input: elan_i2c - Wait for initialization after enabling
 regulator supply

On Tue, Oct 01, 2024 at 05:38:14PM +0800, Chen-Yu Tsai wrote:
> Elan trackpad controllers require some delay after enabling power to
> the controller for the hardware and firmware to initialize:
> 
>   - 2ms for hardware initialization
>   - 100ms for firmware initialization
> 
> Until then, the hardware will not respond to I2C transfers. This was
> observed on the MT8173 Chromebooks after the regulator supply for the
> trackpad was changed to "not always on".
> 
> Add proper delays after regulator_enable() calls.
> 
> Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad")
> Signed-off-by: Chen-Yu Tsai <wenst@...omium.org>
> ---
> This will unfortunately slightly slow down the driver probe and resume.
> An optimization would be to check if the regulator is enabled already,
> and shorten or skip the delay if it is. This would require a new API
> though.
> ---
>  drivers/input/mouse/elan_i2c_core.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
> index ce96513b34f6..89556f61004e 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -46,6 +46,8 @@
>  #define ETP_FWIDTH_REDUCE	90
>  #define ETP_FINGER_WIDTH	15
>  #define ETP_RETRY_COUNT		3
> +/* H/W init 2 ms + F/W init 100 ms w/ round up */
> +#define ETP_POWER_ON_DELAY	110
>  
>  /* quirks to control the device */
>  #define ETP_QUIRK_QUICK_WAKEUP	BIT(0)
> @@ -1237,6 +1239,8 @@ static int elan_probe(struct i2c_client *client)
>  		return error;
>  	}
>  
> +	msleep(ETP_POWER_ON_DELAY);
> +
>  	/* Make sure there is something at this address */
>  	error = i2c_smbus_read_byte(client);
>  	if (error < 0) {
> @@ -1374,6 +1378,8 @@ static int elan_resume(struct device *dev)
>  			dev_err(dev, "error %d enabling regulator\n", error);
>  			goto err;
>  		}
> +
> +		msleep(ETP_POWER_ON_DELAY);

This will add an unwanted delay on ACPI systems that handle power
sequencing in firmware. However use of "optional" regulators is frowned
upon in this case as the supply in reality is not optional.

Mark, has there been any developments that would help reconciling
difference in behavior between ACPI and DT systems. Ideally we'd need to
know when supply was turned on, and adjust the wait accordingly.

Thanks.

-- 
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ