Re: [PATCH 6/6] Input: mms114 - refactor chip variant handling using descriptors

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The input device name exposed to userspace has changed for the MMS134S and MMS345L variants, which risks breaking userspace configurations.
--

commit 6433e094b88447042b6bbde3852dd64f8e938510
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: mms114 - refactor chip variant handling using descriptors

This commit replaces enum-based chip variant checks with a descriptor
structure. It encapsulates variant-specific properties and callbacks into
per-chip descriptors mapped directly via device ID tables.

> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index bf01eee0560a1..006dded17eb80 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c

[ ... ]

> @@ -579,8 +606,8 @@ static int mms114_probe(struct i2c_client *client)
>  	}
>  
> -	input_dev->name = devm_kasprintf(&client->dev, GFP_KERNEL,
> -					 "MELFAS MMS%d Touchscreen",
> -					 data->type);
> +	input_dev->name = devm_kasprintf(&client->dev, GFP_KERNEL,
> +					 "MELFAS %s Touchscreen",
> +					 data->chip->name);

[Severity: Medium]
Could this string format change break userspace configurations that rely on
the exact input device name?

Previously, using the integer type, TYPE_MMS134S (134) resulted in the name
"MELFAS MMS134 Touchscreen", and TYPE_MMS345L (345) resulted in
"MELFAS MMS345 Touchscreen". 

By switching to the descriptor name string, the names now include the trailing
characters ("MELFAS MMS134S Touchscreen" and "MELFAS MMS345L Touchscreen").

Might this disrupt existing hwdb rules or udev scripts matching on the old
UAPI-visible names?

>  	if (!input_dev->name)
>  		return -ENOMEM;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616050912.1531241-1-dmitry.torokhov@gmail.com?part=6