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]
Message-ID: <20190819071413.GI19908@lahna.fi.intel.com>
Date:   Mon, 19 Aug 2019 10:14:13 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Chris Chiu <chiu@...lessm.com>
Cc:     andriy.shevchenko@...ux.intel.com, linus.walleij@...aro.org,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux@...lessm.com
Subject: Re: [PATCH] pinctrl: intel: remap the pin number to gpio offset for
 irq enabled pin

On Fri, Aug 16, 2019 at 05:38:38PM +0800, Chris Chiu wrote:
> On Asus X571GT, GPIO 297 is configured as an interrupt and serves
> for the touchpad. The touchpad will report input events much less
> than expected after S3 suspend/resume, which results in extremely
> slow cursor movement. However, the number of interrupts observed
> from /proc/interrupts increases much more than expected even no
> touching touchpad.
> 
> This is due to the value of PADCFG0 of PIN 225 for the interrupt
> has been changed from 0x80800102 to 0x80100102. The GPIROUTIOXAPIC
> is toggled on which results in the spurious interrupts. The PADCFG0
> of PIN 225 is expected to be saved during suspend, but the 297 is
> saved instead because the gpiochip_line_is_irq() expect the GPIO
> offset but what's really passed to it is PIN number. In this case,
> the /sys/kernel/debug/pinctrl/INT3450:00/gpio-ranges shows
> 
> 288: INT3450:00 GPIOS [436 - 459] PINS [216 - 239]
> 
> So gpiochip_line_is_irq() returns true for GPIO offset 297, the
> suspend routine spuriously saves the content for PIN 297 which
> we expect to save for PIN 225.

Nice work nailing the issue!

> This commit maps the PIN number to GPIO offset first in the
> intel_pinctrl_should_save() to make sure the values for the
> specific PINs can be correctly saved and then restored.
> 
> Signed-off-by: Chris Chiu <chiu@...lessm.com>

Acked-by: Mika Westerberg <mika.westerberg@...ux.intel.com>

I think this should also have:

Fixes: c538b9436751 ("pinctrl: intel: Only restore pins that are used by the driver")

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ