Input: goodix - defer probe when externally reset controller does not answer

On some devices the reset line of the touch controller is sequenced by
external logic rather than by GPIOs under control of the goodix driver.
On the Raspberry Pi Touch Display 2, for example, the reset line is
managed by a microcontroller on the display. In such configurations the
driver has neither a reset GPIO nor access to the irq pin
(IRQ_PIN_ACCESS_NONE), so when the initial I2C test fails there is no
controller-reset retry path and probing fails permanently with -EIO.
Whether the controller answers the first I2C test depends on probe
timing relative to the external reset sequencing, which can shift
between kernel versions and configurations.

Return -EPROBE_DEFER in this case so probing is retried later, in
particular after other drivers (such as the DSI panel driver behind
which the display MCU is brought up) have been bound.

Link: home-assistant/operating-system#4846
Assisted-by: Claude:claude-fable-5
Signed-off-by: Stefan Agner <stefan@agner.ch>

Author: agners

drivers/input/touchscreen/goodix.c

@@ -1378,6 +1378,17 @@ static int goodix_ts_probe(struct i2c_client *client)
 			ts->reset_controller_at_probe = true;
 			goto reset;
 		}
+		/*
+		 * Without reset/irq GPIOs the controller reset is sequenced
+		 * externally (e.g. by the display MCU on the Raspberry Pi
+		 * Touch Display 2) and the controller may simply not be out
+		 * of reset yet. Defer probing so it is retried once the rest
+		 * of the display stack has been brought up.
+		 */
+		if (ts->irq_pin_access_method == IRQ_PIN_ACCESS_NONE)
+			return dev_err_probe(&client->dev, -EPROBE_DEFER,
+					     "I2C communication failure: %d\n",
+					     error);
 		dev_err(&client->dev, "I2C communication failure: %d\n", error);
 		return error;
 	}