| 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
| ||
|
Message-ID: <84af9a9e-5d82-7420-e72c-4d984135f2d6@theobroma-systems.com>
Date: Tue, 22 Nov 2022 17:22:45 +0100
From: Quentin Schulz <quentin.schulz@...obroma-systems.com>
To: Robin Murphy <robin.murphy@....com>,
David Jander <david@...tonic.nl>,
Fabio Estevam <festevam@...il.com>
Cc: Quentin Schulz <foss+kernel@...il.net>,
"Angus Ainslie (Purism)" <angus@...ea.ca>,
Shawn Guo <shawnguo@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Heiko Stuebner <heiko@...ech.de>,
Samuel Holland <samuel@...lland.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Bastien Nocera <hadess@...ess.net>,
Chen-Yu Tsai <wens@...e.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Hans de Goede <hdegoede@...hat.com>,
Andy Gross <agross@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
NXP Linux Team <linux-imx@....com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-input@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
devicetree@...r.kernel.org
Subject: Re: [PATCH RFC v2 5/7] arm64: dts: imx: fix touchscreen reset GPIO
polarity
Hi Robin,
On 11/22/22 13:46, Robin Murphy wrote:
> On 2022-11-22 09:58, Quentin Schulz wrote:
>> Hi David,
>>
>> Thanks Fabio for the Cc.
>>
>> On 11/22/22 08:18, David Jander wrote:
>>> On Mon, 21 Nov 2022 15:18:32 -0300
>>> Fabio Estevam <festevam@...il.com> wrote:
>>>
>>>> [Adding Angus and David]
>>>
>>> Thanks. This was apparently necessary ;-)
>>>
>>>> On Mon, Nov 21, 2022 at 3:12 PM Quentin Schulz
>>>> <foss+kernel@...il.net> wrote:
>>>>>
>>>>> From: Quentin Schulz <quentin.schulz@...obroma-systems.com>
>>>>>
>>>>> The reset line is active low for the Goodix touchscreen controller so
>>>>> let's fix the polarity in the Device Tree node.
>>>>>
>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@...obroma-systems.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts | 2 +-
>>>>> arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts | 2 +-
>>>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
>>>>> b/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
>>>>> index 9fbbbb556c0b3..df7e5ae9698e1 100644
>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
>>>>> @@ -107,7 +107,7 @@ touchscreeen@5d {
>>>>> interrupt-parent = <&gpio1>;
>>>>> interrupts = <8 IRQ_TYPE_NONE>;
>>>>> irq-gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
>>>>> - reset-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
>>>>> + reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
>>>
>>> NACK!
>>>
>>> The PRT8MM has an inverter in the reset line. The reason for that is
>>> that the
>>> reset line needs to be inactive when the driving side is unpowered.
>>> The DT was correct, this change will break it.
>>>
>>
>> The DT was correct. The implementation in the driver is changed (the
>> polarity is swapped) in this patch series, therefore the DT isn't
>> correct anymore, hence this patch.
>
> I'm not sure it's quite that simple... FWIW I'm using an add-on LCD
> module with a GT9271[1] (and I won't be the only one - Raspberry Pi and
> other SBC users using DT overlays or custom-built DTBs are a whole other
> can of worms here), where GPIO_ACTIVE_LOW is correctly specified per the
> schematics, thus "wrong" for the current driver behaviour, yet it *is*
> working OK as-is. I guess that's because /RSTB ends up driven low for
> long enough between the current "deassertion" by
> gpiod_direction_output(1) and gpiod_direction_input() allowing the
> external pull-up to take it high again.
>
Correct, that seems like it is the case for "current-wrong" GPIO level,
provided you have a pull-up on the RESET line (as recommended in the
datasheet).
c.f.
https://github.com/hadess/gt9xx/blob/master/specifications/GT9271%20Datasheet.pdf
with the current driver, what I assume we should get is:
___________________
INT _______| |___________
____________ __________________
RST |_________|
^
L__ pull-up on RST so high by default
^
L___ gpiod_direction_output(0) (deassert GPIO active-low, so high)
^
L____ goodix_irq_direction_output
^
L___ gpiod_direction_output(1) (assert GPIO active-low,
so low)
^
L____ gpiod_direction_input() (floating,
pull-up on RST so high)
This works because of the pull-up on RST and that what matters is that
the INT lane is configured 100µs before a rising edge on RST line (for
at least 5ms). However, the init sequence is not properly followed and
might get broken in the future since it is not something that we
explicitly support.
With the proposed patch:
___________________
INT _______| |___________
____ __________________
RST |_______|
^
L__ pull-up on RST so high by default
^
L___ gpiod_direction_output(1) (assert GPIO active-low, so low)
^
L____ goodix_irq_direction_output
^
L___ gpiod_direction_output(1) (deassert GPIO
active-low, so high)
^
L____ gpiod_direction_input() (floating,
pull-up on RST so high)
This should work too and does not rely on some side effects/timings and
should be future-proof.
As for OOT DTB/DTBO, nothing I can do unfortunately, that is correct.
The fact that we have both "interpretations" of the RESET GPIO level in
Linux is worrying, albeit with OOT DTBs. A driver or subsystem rework
might break boards in which case people should update their DTB as
suggested here or we'll decide to support both interpretations, which
ain't great either.
Cheers,
Quentin
Powered by blists - more mailing lists