Re: [PATCH v8 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The serio->write callback calls a sleeping I2C API, violating the atomic context requirements of the serio subsystem.
- [High] Serio ports are registered before the EC notifier is active, which can lead to dropped hardware ACKs and driver probe timeouts.
--

commit c384b4357257c7b443531cb85e3b65aa83067d31
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>

input: serio: Add driver for ASUS Transformer dock keyboard and touchpad

This commit adds a serio input driver for the ASUS Transformer dock keyboard
and touchpad. It handles incoming scancodes, remaps specific keys to match
the standard AT layout, and forwards the data to the serio subsystem.

Co-developed-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>

[ ... ]

> diff --git a/drivers/input/serio/asus-transformer-ec-kbc.c b/drivers/input/serio/asus-transformer-ec-kbc.c
> new file mode 100644
> index 0000000000000..6f10b7f1baae5
> --- /dev/null
> +++ b/drivers/input/serio/asus-transformer-ec-kbc.c
> @@ -0,0 +1,158 @@
[ ... ]
> +static int asus_ec_serio_write(struct serio *port, unsigned char data)
> +{
> +	struct asus_ec_kbc_data *priv = port->port_data;
> +
> +	return i2c_smbus_write_word_data(priv->parent, ASUSEC_WRITE_BUF,
> +					 (data << 8) | port->id.extra);
> +}

[Severity: High]
Does this code sleep in an atomic context?

The i2c_smbus_write_word_data() function takes the I2C adapter's mutex and
sleeps while waiting for the synchronous transaction to complete. 

However, the serio core and keyboard/mouse drivers frequently call
serio_write() from atomic contexts. For example, the core serio_interrupt()
function holds the port's spinlock with interrupts disabled:

serio_interrupt() {
    guard(spinlock_irqsave)(&serio->lock);
    ...
    serio->drv->interrupt(...) // calls driver interrupt which may write
}

If a driver like atkbd needs to resend a command or respond to a hardware
NAK, it calls serio_write() directly from this interrupt handler.

Executing a sleeping I2C write while holding a spinlock with interrupts
disabled will trigger a "scheduling while atomic" bug or cause a system
deadlock.

[ ... ]
> +static int asus_ec_kbc_probe(struct platform_device *pdev)
> +{
> +	struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> +	struct asus_ec_kbc_data *priv;
> +	int error;
> +
> +	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	priv->ec = ec;
> +	priv->parent = to_i2c_client(pdev->dev.parent);
> +
> +	error = asus_ec_register_serio(pdev, 0, "Keyboard", 0);
> +	if (error)
> +		return error;
> +
> +	error = asus_ec_register_serio(pdev, 1, "Touchpad", I8042_CMD_AUX_SEND);
> +	if (error)
> +		return error;
> +
> +	priv->nb.notifier_call = asus_ec_kbc_notify;
> +
> +	return blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
> +}

[Severity: High]
Can this cause driver probe timeouts by dropping hardware ACKs?

The asus_ec_register_serio() calls are exposing the keyboard and touchpad
to the serio subsystem before the EC notifier is attached. The serio port
registration asynchronously queues work on the kseriod workqueue, which
finds and binds drivers.

Since the kseriod workqueue can run concurrently on another CPU, it may send
initialization commands and the hardware may respond before this probe
function reaches blocking_notifier_chain_register().

Because the notifier is not yet attached to receive and forward these ACKs,
the events will be dropped. This causes the bound driver's probe to time out
and fail, leaving the input devices non-functional.

Should the notifier be fully registered before the serio ports are exposed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528053203.9339-1-clamor95@gmail.com?part=3