Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Heidelberg" <david@ixit.cz>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v8 4/5] Input: stmfts - support FTS5
Date: Fri, 25 Sep 2026 21:33:56 +0000	[thread overview]
Message-ID: <20260925213356.6C08E1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260925-stmfts5-v8-4-0fcf49e2c85f@ixit.cz>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] input: missing ABS_MT_TOOL_TYPE capability breaks stylus/palm reporting
- [Medium] input: missing NULL check for i2c_get_match_data() in probe
--

commit 997befb9927821c565f6d2664205f5c6f9c83d19
Author: David Heidelberg <david@ixit.cz>

Input: stmfts - support FTS5

This commit adds FTS5 support to the STMicroelectronics FTS Touchscreen
driver. It introduces a mode-switch GPIO and device-specific ops to handle
FTS4 and FTS5 variations.

> diff --git a/drivers/input/touchscreen/stmfts.c b/drivers/input/touchscreen/stmfts.c
> index 1720202d6186b..2b9faeef7e462 100644
> --- a/drivers/input/touchscreen/stmfts.c
> +++ b/drivers/input/touchscreen/stmfts.c
[ ... ]
> @@ -656,6 +882,50 @@ static void stmfts_power_off(void *data)
>  	regulator_bulk_disable(ARRAY_SIZE(stmfts_supplies), sdata->supplies);
>  }
>  
[ ... ]
> +static int stmfts5_setup_input(struct stmfts_data *sdata)
> +{
> +	struct device *dev = &sdata->client->dev;
> +
> +	sdata->mode_switch_gpio = devm_gpiod_get_optional(dev, "mode-switch",
> +							  GPIOD_OUT_HIGH);
> +	if (IS_ERR(sdata->mode_switch_gpio))
> +		return dev_err_probe(dev, PTR_ERR(sdata->mode_switch_gpio),
> +				     "Failed to get GPIO 'switch'\n");
> +
> +	/* Set resolution for accurate calibration */
> +	if (!input_abs_get_res(sdata->input, ABS_MT_POSITION_X)) {
> +		input_abs_set_res(sdata->input, ABS_MT_POSITION_X, 10);
> +		input_abs_set_res(sdata->input, ABS_MT_POSITION_Y, 10);
> +	}
> +
> +	input_set_abs_params(sdata->input, ABS_MT_DISTANCE, 0, 255, 0, 0);
> +
> +	/* Enable stylus support if requested */
> +	sdata->stylus_enabled = device_property_read_bool(dev, "stylus-enabled");
> +
> +	return input_mt_init_slots(sdata->input, STMFTS_MAX_FINGERS,
> +				   INPUT_MT_DIRECT);

[Severity: Medium]
Will this break stylus and palm reporting?

In stmfts5_setup_input(), the driver configures absolute axes but omits calling
input_set_abs_params() for ABS_MT_TOOL_TYPE.

Later, when stmfts5_report_contact_event() attempts to report MT_TOOL_PEN or
MT_TOOL_PALM using input_mt_report_slot_state(), won't the input core discard
these tool type events because ABS_MT_TOOL_TYPE is missing from dev->absbit?

> +}
> +
[ ... ]
> @@ -701,6 +971,8 @@ static int stmfts_probe(struct i2c_client *client)
>  	mutex_init(&sdata->mutex);
>  	init_completion(&sdata->cmd_done);
>  
> +	sdata->ops = i2c_get_match_data(client);
> +

[Severity: Medium]
Is it possible for i2c_get_match_data() to return NULL here if the driver is
bound to an I2C device via sysfs using the driver_override attribute?

>  	err = devm_regulator_bulk_get_const(dev,
>  					    ARRAY_SIZE(stmfts_supplies),
>  					    stmfts_supplies,
> @@ -728,18 +1000,9 @@ static int stmfts_probe(struct i2c_client *client)
>  
>  	input_set_abs_params(sdata->input, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
>  	input_set_abs_params(sdata->input, ABS_MT_TOUCH_MINOR, 0, 255, 0, 0);
> -	input_set_abs_params(sdata->input, ABS_MT_ORIENTATION, 0, 255, 0, 0);
>  	input_set_abs_params(sdata->input, ABS_MT_PRESSURE, 0, 255, 0, 0);
> -	input_set_abs_params(sdata->input, ABS_DISTANCE, 0, 255, 0, 0);
>  
> -	sdata->use_key = device_property_read_bool(dev, "touch-key-connected");
> -	if (sdata->use_key) {
> -		input_set_capability(sdata->input, EV_KEY, KEY_MENU);
> -		input_set_capability(sdata->input, EV_KEY, KEY_BACK);
> -	}
> -
> -	err = input_mt_init_slots(sdata->input,
> -				  STMFTS_MAX_FINGERS, INPUT_MT_DIRECT);
> +	err = sdata->ops->setup_input(sdata);

[Severity: Medium]
If i2c_get_match_data() returned NULL above, will this result in a NULL
pointer dereference?

>  	if (err)
>  		return err;

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

  reply	other threads:[~2026-09-25 21:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 21:22 [PATCH v8 0/5] Input: support for STM FTS5 David Heidelberg via B4 Relay
2026-09-25 21:22 ` [PATCH v8 1/5] Input: stmfts - wait for controller ready after reset David Heidelberg via B4 Relay
2026-09-25 21:35   ` sashiko-bot
2026-09-25 22:18   ` Dmitry Torokhov
2026-09-25 21:22 ` [PATCH v8 2/5] dt-bindings: input: touchscreen: st,stmfts: Improve example David Heidelberg via B4 Relay
2026-09-29  8:28   ` Krzysztof Kozlowski
2026-09-25 21:22 ` [PATCH v8 3/5] dt-bindings: input: touchscreen: st,stmfts: Introduce STM FTS5 David Heidelberg via B4 Relay
2026-09-25 21:32   ` sashiko-bot
2026-09-29  8:40   ` Krzysztof Kozlowski
2026-09-25 21:22 ` [PATCH v8 4/5] Input: stmfts - support FTS5 David Heidelberg via B4 Relay
2026-09-25 21:33   ` sashiko-bot [this message]
2026-09-25 21:22 ` [PATCH v8 5/5] arm64: dts: qcom: sdm845-google: Add STM FTS touchscreen support David Heidelberg via B4 Relay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260925213356.6C08E1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=david@ixit.cz \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox