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
| ||
|
Date: Thu, 3 Jul 2014 09:09:55 -0700 From: Sören Brinkmann <soren.brinkmann@...inx.com> To: Daniel Lezcano <daniel.lezcano@...aro.org> CC: Thomas Gleixner <tglx@...utronix.de>, <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org> Subject: Re: timers & suspend On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote: > On 06/30/2014 08:39 PM, Sören Brinkmann wrote: > >Hi, > > > >I'm currently working on suspend for Zynq and try to track down some > >spurious wakes. It looks like the spurious wakes are caused by timers, > >hence I was wondering whether there are any special requirements for > >timer drivers when it comes to suspend support or if I just missed > >something. > > > >Zynq sets the 'IRQCHIP_MASK_ON_SUSPEND' flag, which should mask all > >interrupts but the wake source. Reading through kernel/irq/pm.c > >indicates, that timer interrupts get some special treatment though. > >Therefore I implemented some suspend/resume callbacks for the > >cadence_ttc which disable and clear the timer's interrupts when going > >into suspend. That seems to mitigate the issue quite a bit, but I still > >saw spurious wakes - just a lot less often. > >Digging a little deeper revealed, the spurious wakes are caused by the > >ARM's smp_twd timer now. Given that that driver is probably used by a few > >more ARM platforms, I get the feeling that I'm missing something. > > Do you receive any interrupt from the cadence_ttc ? (/proc/interrupts) > > That's funny because I realize that you cadence ttc timer is never > used as there are the architected timers. The cadence ttc would be > only useful if there were an idle state powering down the smp_twd > timers but it is not the case on this board, IIUC. Yes they are used. They TTC is the only broadcast capable timer for Zynq. In my experience, I can not even boot without it (may have dependencies on CPUidle or something). > > >It's probably worth mentioning that the suspend state in Zynq does not > >power off the CPU cores. It just asserts the resets on secondary cores > >and the primary one waits in wfi. > > Why do you need to reset them ? CPU0 is not reset, but all secondary cores are. That is as close to power off as we get and works well with hotplug. Sören -- 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