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] [day] [month] [year] [list]
Message-ID: <5174CFA3.6020402@ti.com>
Date:	Mon, 22 Apr 2013 11:20:27 +0530
From:	Sourav Poddar <sourav.poddar@...com>
To:	Kevin Hilman <khilman@...aro.org>
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

Hi Kevin,
On Friday 19 April 2013 08:22 PM, Kevin Hilman wrote:
> 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?
Yes, that can be done.
> (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.
>
True.

~Sourav
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ