Input: goodix - defer probe when externally reset controller does not answer#7482
Open
agners wants to merge 1 commit into
Open
Input: goodix - defer probe when externally reset controller does not answer#7482agners wants to merge 1 commit into
agners wants to merge 1 commit into
Conversation
… 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>
77ec19b to
3824f43
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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. The same failure signature has also been reported against Raspberry Pi OS, e.g. after warm reboots: https://forums.raspberrypi.com/viewtopic.php?t=389937This 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.
🤖 Generated with Claude Code