Re: [PATCH v8 1/5] Input: stmfts - wait for controller ready after reset

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] input: stmfts: premature command completion due to missing event flush
--

commit 980291fffea4f1302d4d35aa190de1039c220daa
Author: David Heidelberg <david@ixit.cz>

    Input: stmfts - wait for controller ready after reset
    
This commit removes fixed sleeps in favor of waiting for a controller ready
event after reset. It adds a wait_for_completion_timeout for the reset
GPIO path, while preserving a 70ms sleep for boards without a reset GPIO.

> diff --git a/drivers/input/touchscreen/stmfts.c b/drivers/input/touchscreen/stmfts.c
> index 972687797f826..1720202d6186b 100644
> --- a/drivers/input/touchscreen/stmfts.c
> +++ b/drivers/input/touchscreen/stmfts.c
[ ... ]
> @@ -587,27 +580,50 @@ static int stmfts_power_on(struct stmfts_data *sdata)
[ ... ]
> +	} else {
> +		/*
> +		 * We do not know the real controller state (was it powered
> +		 * off or reset). Let's hope that this is enough time to
> +		 * initialize.
> +		 */
> +		msleep(70);
> +
> +		enable_irq(sdata->client->irq);
> +	}
>  
> -	msleep(50);
> +	err = stmfts_read_system_info(sdata);
> +	if (err)
> +		goto err_disable_irq;
>  
>  	err = stmfts_configure(sdata);

[Severity: High]
Does removing the msleep(50) here introduce a race condition on boards
without a reset GPIO?

By enabling the IRQ and immediately proceeding without the 50ms flush window,
the threaded IRQ handler can process the pending STMFTS_EV_CONTROLLER_READY
boot event concurrently with stmfts_configure().

If stmfts_configure() calls stmfts_command() to send STMFTS_SYSTEM_RESET:

stmfts_command()
    reinit_completion(&sdata->cmd_done);
    err = i2c_smbus_write_byte(sdata->client, cmd);
    ...
    if (!wait_for_completion_timeout(&sdata->cmd_done, ...))

And the concurrent IRQ handler processes the boot event and completes the
same completion:

IRQ handler
    ...
    complete(&sdata->cmd_done);

Will this cause the wait_for_completion_timeout() in stmfts_command() to
falsely succeed before the hardware actually processes the reset command?

If so, the driver might send subsequent initialization commands while the
hardware is still physically executing the reset, potentially causing the
touchscreen to fail.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925-stmfts5-v8-0-0fcf49e2c85f@ixit.cz?part=1