Re: [PATCH regression fix 1/1] Input: goodix - Try not to touch the reset-pin on x86/ACPI devices

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Mon, Dec 06, 2021 at 10:11:16AM +0100, Hans de Goede wrote:
> Unless the controller is not responding at boot or after suspend/resume,
> the driver never resets the controller on x86/ACPI platforms. The driver
> still requesting the reset pin at probe() though in case it needs it.
> 
> Until now the driver has always requested the reset pin with GPIOD_IN
> as type. The idea being to put the pin in high-impedance mode to save
> power until the driver actually wants to issue a reset.
> 
> But this means that just requesting the pin can cause issues, since
> requesting it in another mode then GPIOD_ASIS may cause the pinctrl
> driver to touch the pin settings. We have already had issues before
> due to a bug in the pinctrl-cherryview.c driver which has been fixed in
> commit 921daeeca91b ("pinctrl: cherryview: Preserve
> CHV_PADCTRL1_INVRXTX_TXDATA flag on GPIOs").
> 
> And now it turns out that requesting the reset-pin as GPIOD_IN also stops
> the touchscreen from working on the GPD P2 max mini-laptop. The behavior
> of putting the pin in high-impedance mode relies on there being some
> external pull-up to keep it high and there seems to be no pull-up on the
> GPD P2 max, causing things to break.
> 
> This commit fixes this by requesting the reset pin as is when using
> the x86/ACPI code paths to lookup the GPIOs; and by not dropping it
> back into input-mode in case the driver does end up issuing a reset
> for error-recovery.
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209061
> Fixes: a7d4b171660c ("Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices")
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Applied, thank you.

-- 
Dmitry