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:   Fri, 17 Nov 2017 15:35:18 +0200
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Chris Chiu <chiu@...lessm.com>
Cc:     Daniel Drake <drake@...lessm.com>, heikki.krogerus@...ux.intel.com,
        linux-gpio@...r.kernel.org,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Endless Linux Upstreaming Team <linux@...lessm.com>,
        Jarkko Nikula <jarkko.nikula@...ux.intel.com>
Subject: Re: intel-gpio interrupts stop firing with Focaltech I2C-HID touchpad

On Fri, Nov 17, 2017 at 09:21:48PM +0800, Chris Chiu wrote:
> On Fri, Nov 17, 2017 at 7:00 PM, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> > On Fri, Nov 17, 2017 at 06:01:27PM +0800, Chris Chiu wrote:
> >> Hi Mika,
> >>     Here's the full dmesg log you need. The touchpad stop reporting at
> >> the last of the log.
> >> https://gist.github.com/mschiu77/a0b8d24a586a228c55eca30c87c71d41
> >
> > Thanks!
> >
> > I did not spot anything suspicious in the i2c-hid initialization. When
> > the issue happens, can you check what the pin state is and if it changes
> > when you use the touchpad? If I read your ACPI tables right, something
> > like this:
> >
> >   # grep GPIO_18 /sys/kernel/debug/pinctrl/INT3452:00/pins
> >
> > (it could be another INT3452:* device as well).
> >
> > The GPIO line should be high and when the touchpad is pressed it should
> > go low.
> >
> > Then another thing, if you unload i2c-hid and load it back, does it
> > start working again?
> >
> >   # modprobe -r i2c-hid
> >   # modprobe i2c-hid
> 
> Yup. We did the same inspection on /sys/kernel/debug/pinctrl/INT3452:00/pins
> before and after the touchpad stop working.
> Before touchpad stop working, most of the results would be
> pin 18 (GPIO_18) GPIO 0x40900102 0x00024075
> After touchpad stop working, the result would always be
> pin 18 (GPIO_18) GPIO 0x40900100 0x00024075

OK, so the line (as being active low) gets pulled to low and is never
released back.

Does /proc/interrupts show that the interrupt counts are still
increasing (for both the GPIO driver and the touchpad)?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ