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:	Wed, 6 May 2009 01:27:23 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] PM: suspend_device_irqs(): don't disable wakeup IRQs

On Wednesday 06 May 2009, Kevin Hilman wrote:
> Arve Hjønnevåg <arve@...roid.com> writes:
> 
> > On Tue, May 5, 2009 at 8:52 AM, Kevin Hilman
> > <khilman@...prootsystems.com> wrote:
> >> Andrew Morton <akpm@...ux-foundation.org> writes:
> >>
> >>> On Mon,  4 May 2009 17:27:04 -0700 Kevin Hilman <khilman@...prootsystems.com> wrote:
> >>>
> >>>> Interrupts that are flagged as wakeup sources via set_irq_wake()
> >>>> should not be disabled for suspend.
> >>>>
> >>>
> >>> Why not?
> >>>
> >>
> >> If an interrupt is a wakeup source, and it is disabled at the chip
> >> level, it will no longer generate interrupts, and thus no longer wake
> >> up the system.
> >>
> >> I'd be interested in hearing why wakeup interrupts should be disabled
> >> during suspend.

That depends on whether or not they are used for anything else than wake-up.

> 
> [...]
> 
> >>>
> >>> If this fixes some bug then please provide a description of that bug?
> >>
> >> The bug is that on TI OMAP, interrupts that are used for wakeup events
> >> are disabled by this code causing the system to no longer wake up.
> >
> > What do you do if the interrupt triggers right after your driver has
> > returned from its late suspend hook?  
> 
> If it's a wakeup IRQ, I assume you want it to prevent suspend.
> 
> But I don't see how that can happen in the current code. IIUC, by the
> time your late suspend hook is run, your device IRQ is already
> disabled, so it won't trigger an interrupt that will be caught by
> check_wakeup_irqs() anyways.

My understanding of __disable_irq() was that it didn't actually disable the
IRQ at the hardware level, allowing the CPU to actually receive the interrupt
and acknowledge it, but preventing the device driver for receiving it.  Does
it work differently on the affected systems?

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ