linux-kernel - Re: [PATCH] Input: goodix - decouple irq and reset lines

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 7 Jan 2019 10:13:56 +0000
From:   "Gonzalez, Alex" <Alex.Gonzalez@...i.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:     "hadess@...ess.net" <hadess@...ess.net>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Input: goodix - decouple irq and reset lines

Hi Dmitry,

Thanks for your quick reply.

>
>I do not have a datasheet for the device, so I am not sure if reset line
>is actually needed to put the device into sleep mode. As far as I can
>see from the code we suspend it by pulsing INT line and then sending a
>command to the controller, and resuming by pulsing the INT line again.
>So it sounds to me INT only designs _could_ place device in sleep mode.
>

The way I read the gt911 dataheet I also understand that only the INT line is
required to enter sleep mode but I don't other for the other supported 
controllers.  My comment is based on both the suspend() and resume() functions 
returning in the absence of either gpiod_int or gpiod_rst and not progressing 
to the sleep sequence.

>As far as the patch goes, if you do not need to execute reset or put
>device into low power mode, you do not need to specify any of the GPIOs
>as GPIO resources. Simply specify the INT GPIO as your interrupt source
>(GpioInt() in ACPI world or "interrupts = <&gpio NNN
>IRQF_TRIGGER_WHATEVER>" in DT world and be done with it.
>

That was my first impression too. However this does not work for my device. My
hypothesis is that the touch controller I2C address setting sequence is not 
happening as it should, so I need at least the control of the INT line in 
order to fix the I2C address.

I am unsure though whether this is a problem specific to the design I am 
testing with or all designs will have problems setting the I2C address without 
controlling the INT GPIO line.

Regards,
Alex

>Thanks.
>
>--
>Dmitry