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

[agners]

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.

---

Note: This addresses a regression observed on Home Assistant OS 18.1 (kernel 6.18.x), where the Goodix touch controller of the Raspberry Pi Touch Display 2 stopped probing with I2C communication failure: -5, see home-assistant/operating-system#4846.

Related reports of the same failure signature:

• Touch Display 2 touch not working after warm reboot on Raspberry Pi OS (Error reading 1 bytes from 0x8140: -5, probe with driver Goodix-TS failed with error -5; the rmmod goodix_ts && modprobe goodix_ts workaround reported there is the manual equivalent of the deferred probe retry): https://forums.raspberrypi.com/viewtopic.php?t=389937
• Possibly related: Goodix touchscreen probe failure (I2C communication failure: -6) on Pi 5 with a Waveshare panel: RPI 5 - Goodix capacitive touchscreen not working on latest Kernel #6456

This is untested on my end, but it seems a very plausible fix. Hence I did not send it upstream for now — but since the affected code path is unmodified mainline code, if this turns out to be the correct fix, anyone is welcome to pick it up and upstream it.

Note on the advisory checkpatch failure: the commit uses the Assisted-by: AGENT_NAME:MODEL_VERSION tag as accepted by current mainline checkpatch/docs; the 6.18-based checkpatch here predates that tag, hence the warning/error.

🤖 Generated with Claude Code

[agners]

It seems Assisted-by: Claude:claude-fable-5 is valid on master, maybe this is a checkpatch caveat of 6.18?

I can drop the tag or add some note inline in the commit message if preferred.

[pelwell]

You can leave it as-is - the warning is about the commit message, not the code, so we should only see it once per branch for the older kernels.

[6by9]

home-assistant/operating-system#4846 says that HAOS 18.0 was OK but 18.1 isn't.
What kernel version were you using on 18.0 so that we can compare?

Generally device drivers don't implement retry paths in the probe should communication to the module fail, so more fundamentally we want to understand why the touch controller isn't responding.

[6by9]

The GT911 should be out of reset before goodix_i2c_test completes as the overlay includes

startup-delay-us = <50000>;

on the regulator, so that's at least 50ms, and then goodix_i2c_test includes a retry with 20ms timeout.