linux-kernel - Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.

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

Message-ID: <CAMQu2gz0-U4GxEpZFfmJec+0FRs7ugy8EYS3HyYhb1jwbMBjug@mail.gmail.com>
Date:	Sun, 26 Aug 2012 09:47:50 +0530
From:	"Shilimkar, Santosh" <santosh.shilimkar@...com>
To:	NeilBrown <neilb@...e.de>
Cc:	Tarun Kanti DebBarma <tarun.kanti@...com>,
	Kevin Hilman <khilman@...com>,
	Tony Lindgren <tony@...mide.com>, Cousson@...e.de,
	Benoit <b-cousson@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Felipe Balbi <balbi@...com>, linux-omap@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	Jon Hunter <jon-hunter@...com>
Subject: Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.

+ Jon,

On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown <neilb@...e.de> wrote:
>
>
>
> Current kernel will wake from suspend on an event on any active
> GPIO even if enable_irq_wake() wasn't called.
>
> There are two reasons that the hardware wake-enable bit should be set:
>
> 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
>   in which the wake-enable bit is needed for an interrupt to be
>   recognised.
> 2/ while suspended the GPIO interrupt should wake from suspend if and
>    only if irq_wake as been enabled.
>
> The code currently doesn't keep these two reasons separate so they get
> confused and sometimes the wakeup flags is set incorrectly.
>
> This patch reverts:
>  commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
>     gpio/omap: remove suspend/resume callbacks
> and
>  commit 0aa2727399c0b78225021413022c164cb99fbc5e
>     gpio/omap: remove suspend_wakeup field from struct gpio_bank
>
> and makes some minor changes so that we have separate flags for "GPIO
> should wake from deep idle" and "GPIO should wake from suspend".
>
> With this patch, the GPIO from my touch screen doesn't wake my device
> any more, which is what I want.
>
> Cc: Kevin Hilman <khilman@...com>
> Cc: Tony Lindgren <tony@...mide.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@...com>
> Cc: Cousson, Benoit <b-cousson@...com>
> Cc: Grant Likely <grant.likely@...retlab.ca>
> Cc: Tarun Kanti DebBarma <tarun.kanti@...com>
> Cc: Felipe Balbi <balbi@...com>
> Cc: Govindraj.R <govindraj.raja@...com>
>
> Signed-off-by: NeilBrown <neilb@...e.de>
>
The patch doesn't seems to be correct. At least the 2/ gets
fixed with a proper IRQCHIP flag. Can you try the patch at
end of the email and see if it helps ? Am attaching it in case
mailer damages it.

Regards
Santosh

>From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@...com>
Date: Sun, 26 Aug 2012 09:39:51 +0530
Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
 non-wakeup gpio wakeups.

Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
to mask all non-wake gpios in suspend, which will ensure the wakeup enable
bit is not set on non-wake gpios.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@...com>
---
 drivers/gpio/gpio-omap.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index e6efd77..50b4c18 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
 	.irq_unmask	= gpio_unmask_irq,
 	.irq_set_type	= gpio_irq_type,
 	.irq_set_wake	= gpio_wake_enable,
+	.flags		= IRQCHIP_MASK_ON_SUSPEND;
 };

 /*---------------------------------------------------------------------*/
-- 
1.7.9.5

Download attachment "0001-gpio-omap-Set-IRQCHIP_MASK_ON_SUSPEND-to-mask-all-no.patch" of type "application/octet-stream" (1020 bytes)