linux-kernel - Re: [RFC PATCH 0/7] fix reset line polarity for Goodix touchscreen controllers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y2P3jyz1L0yKsCk8@google.com>
Date:   Thu, 3 Nov 2022 10:17:03 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Quentin Schulz <foss+kernel@...il.net>
Cc:     hadess@...ess.net, hdegoede@...hat.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, shawnguo@...nel.org,
        s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
        linux-imx@....com, wens@...e.org, jernej.skrabec@...il.com,
        samuel@...lland.org, agross@...nel.org, andersson@...nel.org,
        konrad.dybcio@...ainline.org, heiko@...ech.de,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
        linux-rockchip@...ts.infradead.org,
        Quentin Schulz <quentin.schulz@...obroma-systems.com>
Subject: Re: [RFC PATCH 0/7] fix reset line polarity for Goodix touchscreen
 controllers

Hi Quentin,

On Thu, Nov 03, 2022 at 03:43:45PM +0100, Quentin Schulz wrote:
> The Goodix touchscreen controller has a reset line active low. It happens to
> also be used to configure its i2c address at runtime. If the reset line is
> incorrectly asserted, the address will be wrongly configured. This cost me a few
> hours yesterday, trying to figure out why the touchscreen wouldn't work.
> 
> The driver is "asserting" this reset GPIO by setting its output to 0, probably
> to reflect the physical state of the line. However, this relies on the fact that
> the Device Tree node setting the reset line polarity to active high, which is
> incorrect since the reset is active low in hardware.
> 
> To fix this inconsistency, the polarity is inverted to not confuse the user
> about the reset line polarity.
> 
> This is marked as RFC because it breaks DT compatibility and also the Google
> CoachZ device is the only one with an active low polarity for the reset GPIO
> in DT, so not sure if it is a typo or its state is actually inverted (so GPIO
> active high to drive the reset line low). Changing it anyways since the polarity
> is changed in the driver so it needs to be changed in DT too.

I would like to get gpio handling into a better shape, but the above is
completely incorrect. "goodix,gt7375p" that is used in CoachZ and other
Google designs is using i2c-hid compatible firmware and is not being
driven by drivers/input/touchscreen/goodix.c driver, but rather by
i2c-hid + hid-multitouch combo.

You should not be touching arch/arm64/boot/dts/qcom/sc7180* at all.

> 
> I'm all ears if there's a better way to handle this. We could document this in
> the DT binding but this kinda breaks the promise we make that the DT is not
> bound to the driver implementation.

I think Hans has already voiced concerns about x86 devices using these
devices and having GPIO data encoded in the driver, so we need to
accommodate them. On DT side we can add a quirk to gpiolib-of.c to
[maybe temporary] override polarity of reset GPIO lines, then update DTS
to match the reality.

Thanks.

-- 
Dmitry