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: Fri, 19 Apr 2013 07:52:23 -0700 From: Kevin Hilman <khilman@...aro.org> To: Sourav Poddar <sourav.poddar@...com> Cc: <gregkh@...uxfoundation.org>, <tony@...mide.com>, <rmk+kernel@....linux.org.uk>, <linux-serial@...r.kernel.org>, <linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 4/6] arm: mach-omap2: remove "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check Sourav Poddar <sourav.poddar@...com> writes: [...] > Yes, got your point. omap_device_idle should not be called only > for console uart. > > Just did a quick testing by including the following hunk on top of my > patch series.. > > diff --git a/arch/arm/mach-omap2/omap_device.c > b/arch/arm/mach-omap2/omap_device.c > index c226946..7480e87 100644 > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -617,8 +617,10 @@ static int _od_suspend_noirq(struct device *dev) > ret = pm_generic_suspend_noirq(dev); > > if (!ret && !pm_runtime_status_suspended(dev)) { > - if (pm_generic_runtime_suspend(dev) == 0) > + if (pm_generic_runtime_suspend(dev) == 0) { > + omap_device_idle(pdev); > od->flags |= OMAP_DEVICE_SUSPENDED; > + } > } > > return ret; > @@ -631,6 +633,7 @@ static int _od_resume_noirq(struct device *dev) > > if ((od->flags & OMAP_DEVICE_SUSPENDED) && > !pm_runtime_status_suspended(dev)) { > + omap_device_enable(pdev); > od->flags &= ~OMAP_DEVICE_SUSPENDED; > pm_generic_runtime_resume(dev); > } > And found the wakeup from UART is no more functional. > So, the omap_device_idle gets called for console UART also, thereby > preventing the "no_idle_on_suspend" theory. > > Hence, merely putting prepare/complete callback the way I did is not > helping. > We need to delete omap_device_idle also, which I agree is not correct. > So, we need a way to bypass this "omap_device_idle" > call for console UART. ? OK, I see what's happening now. How about this: rather than using prepare/complete callbacks, can you use the runtime_suspend callback to return an error code during suspend? (only for the console, and only when no_console_suspend is enabled, and only during suspend) Since _od_suspend_noirq checks to be sure the drivers ->runtime_suspend callback succeeds before it calls omap_device_idle(), if you report a failure, omap_device_idle will not be called. Kevin -- 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