Re: [PATCH] Input: psmouse-smbus - schedule deferred rescan when adapter present but device not ready

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Infinite unbind/rebind loop breaks the PS/2 fallback if the SMBus companion device never responds.
--

commit 18a210ed3c950add4486fdb9a71222e2b1590d6a
Author: Raphaël Larocque <rlarocque@disroot.org>

Input: psmouse-smbus - schedule deferred rescan when adapter present but device not ready

This commit addresses an issue where the SMBus adapter is registered early
but the companion device is not yet responsive. It schedules a deferred
rescan using a delayed work queue to retry the probe without blocking boot.

> diff --git a/drivers/input/mouse/psmouse-smbus.c b/drivers/input/mouse/psmouse-smbus.c
> index 7fb4cbb2aca2f..704d8c2a028ba 100644
> --- a/drivers/input/mouse/psmouse-smbus.c
> +++ b/drivers/input/mouse/psmouse-smbus.c

[ ... ]

> +static void psmouse_smbus_rescan_work_fn(struct work_struct *work)
> +{
> +	struct psmouse_smbus_dev *smbdev =
> +		container_of(to_delayed_work(work),
> +			     struct psmouse_smbus_dev, rescan_work);
>  
>  	guard(mutex)(&psmouse_smbus_mutex);
>  
> +	if (!smbdev->dead && !smbdev->client) {
> +		psmouse_dbg(smbdev->psmouse,
> +			    "SMBus adapter present but device not yet ready, retrying\n");
> +		serio_rescan(smbdev->psmouse->ps2dev.serio);

[Severity: High]
Does this serio_rescan() call introduce an infinite unbind/rebind loop if the
SMBus companion device never responds?

When serio_rescan() triggers, it tears down the PS/2 driver and initiates a
reprobe. During the reprobe, psmouse_smbus_init() runs again.

> +	}
> +}

[ ... ]

> @@ -290,6 +372,18 @@ int psmouse_smbus_init(struct psmouse *psmouse,
>  		}
>  
>  		kfree(smbdev);
> +	} else if (smbdev->adapter_seen) {
> +		/*
> +		 * A HOST_NOTIFY-capable adapter was already registered when we
> +		 * scanned (so BUS_NOTIFY_ADD_DEVICE has already fired for it
> +		 * and won't fire again), but the companion device at 0x2c was
> +		 * not yet responsive — typical of a cold boot on machines like
> +		 * the ThinkPad T440p.  Schedule a deferred rescan so we retry
> +		 * without blocking the boot path, mirroring what
> +		 * psmouse_smbus_check_adapter() does for late-arriving adapters.
> +		 */
> +		queue_delayed_work(psmouse_smbus_wq, &smbdev->rescan_work,
> +				   msecs_to_jiffies(PSMOUSE_SMBUS_RESCAN_DELAY_MS));
>  	}
>  
>  	return error < 0 ? error : -EAGAIN;

[Severity: High]
If the I2C device is permanently unresponsive (e.g. the hardware is physically
wired only for PS/2 despite firmware capabilities), won't the reprobe hit this
path again?

Since a new smbdev is allocated on every probe and there is no persistent
state tracking the retry count, this appears to unconditionally queue the
rescan again.

This would repeatedly destroy and recreate the PS/2 fallback every 1 second,
rendering the touchpad unusable. Can we limit the number of retry attempts or
track the state to avoid this loop?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604131211.9442-1-rlarocque@disroot.org?part=1