Re: [PATCH 4/8] dt-bindings: input: microchip,cap11xx: Add reset-gpios property

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The driver fails to probe when a Device Tree fallback compatible string is used because it rigidly requires an exact I2C device ID match.
--

commit 804bdcc3e4e43cb8aa1a476f171c69be30e83854
Author: Jun Yan <jerrysteve1101@gmail.com>

dt-bindings: input: microchip,cap11xx: Add reset-gpios property

Add support for the optional reset-gpios property to describe
the active-high reset pin for CAP1126/CAP1188 devices.
Driving the GPIO high asserts reset and deep sleep, while driving
it low releases reset for normal operation.

Restrict this property to be available only on CAP1126 and CAP1188
chips, as other CAP11xx variants do not have a hardware reset pin.

> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index 99d00f572a2d9..e307628350c24 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but since we are updating
bindings for this hardware, is the I2C ID matching in the driver too
strict for standard Device Tree fallback compatibles?

Looking at cap11xx_i2c_probe() in drivers/input/keyboard/cap11xx.c:

	id = i2c_client_get_device_id(i2c_client);
	cap = i2c_get_match_data(i2c_client);
	if (!id || !cap || !cap->num_channels) {
		dev_err(dev, "Invalid device configuration\n");
		return -EINVAL;
	}

When a device is instantiated from a Device Tree using a fallback compatible
string (e.g., compatible = "vendor,custom-board", "microchip,cap1188"), the
I2C core sets client->name to the local string without the vendor prefix.

Because this local name is not present in the cap11xx_i2c_ids table,
i2c_client_get_device_id() evaluates to NULL and completely aborts the probe.

Could this early exit be updated so that valid I2C clients instantiated via
fallback compatibles are not erroneously rejected?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260606150458.250606-1-jerrysteve1101@gmail.com?part=4