linux-kernel - Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using "no_console

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:	Mon, 15 Apr 2013 17:25:48 +0530
From:	Sourav Poddar <sourav.poddar@...com>
To:	Kevin Hilman <khilman@...aro.org>
CC:	"Bedia, Vaibhav" <vaibhav.bedia@...com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"tony@...mide.com" <tony@...mide.com>,
	"rmk+kernel@....linux.org.uk" <rmk+kernel@....linux.org.uk>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	"Shilimkar, Santosh" <santosh.shilimkar@...com>,
	"Balbi, Felipe" <balbi@...com>, "Nayak, Rajendra" <rnayak@...com>
Subject: Re: [PATCHv3] driver: serial: prevent UART console idle on suspend
 while using "no_console_suspend"

Hi Kevin,
On Thursday 11 April 2013 07:45 PM, Kevin Hilman wrote:
> Kevin Hilman<khilman@...aro.org>  writes:
>
>> "Bedia, Vaibhav"<vaibhav.bedia@...com>  writes:
>>
>>> Hi Sourav,
>>>
>>> On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
>>> [...]
>>>> Yes, had a look at that and found your situation similar to UART.
>>>>
>>>> But how exactly this gets used, I mean I don't  see any drivers/ in mainline
>>>> making use of this compatible string  "ti,am3352-ocmcram".  ?
>>> OCMC clock is enabled during bootup (not sure whether that's the h/w
>>> default or ROM does it) since the initial bootloader runs from there.
>>> By marking the corresponding hwmod with HWMOD_INIT_NO_IDLE we leave the
>>> clock running. Right now the sram code under arch/arm/plat-omap/ is what
>>> manages the OCMC. I guess this needs to move somewhere under drivers/
>>> and start managing the clocks. Even then we'll need a mechanism
>>> to leave the clocks running as part of the kernel suspend process
>>> since the assembly code which runs at the fag end of the suspend
>>> process runs out of OCMC and hence we can't cut its clock.
>>>
>>> On AM335x, the OCMC clock is cut to have PER power domain transition
>>> but that's done in the WKUP-M3 firmware when going down. During the
>>> wakeup sequence, WKUP-M3 re-enables the OCMC clock so that when the
>>> kernel resumes the h/w state is same.
>> OK, but *today*, in *mainline*, where in the linux kernel (not the M3
>> firmware) is the OCMRAM clock cut during suspend?
>>
>>  From what I can see, there is no driver for this device, so there are no
>> system PM calls being done for that device, and thus no omap_device
>> calls being done for that device, so the no_idle_on_suspend has no
>> effect.
> OK, I think I confused things here, sorry. I was thinking runtime PM
> here, but wrote system PM.  The no_idle_on_suspend feature only affects
> system PM, and the omap_device calls will still be called during system
> PM, even without a driver.
>
> That being said, the commit below[1], added in v3.6 should prevent the
> any automaic clock gating for devices without drivers bound.  Since
> there is no driver for the OCM RAM block, you shouldn't be affected by
> the automatic idle on suspend anyways.
>
> So, my proposal is that Sourav remove that flag from the AM33xx hwmod
> when he removes this feature.
>
> Kevin
>
Thanks a lot for your inputs and helping in bringing this thread to
a logical conclusion.

I will post a v4 for this patch along with other fixes/cleanups
required as recommended by you and russell.

Thanks,
Sourav
> [1]
> commit 72bb6f9b51c82c820ddef892455a85b115460904
> Author: Kevin Hilman<khilman@...com>
> Date:   Tue Jul 10 15:29:04 2012 -0700
>
>      ARM: OMAP: omap_device: don't attempt late suspend if no driver bound
>
>      Currently, the omap_device PM domain layer uses the late suspend and
>      early resume callbacks to ensure devices are in their low power
>      states.
>
>      However, this is attempted even in cases where a driver probe has
>      failed.  If a driver's ->probe() method fails, the driver is likely in
>      a state where it is not expecting its runtime PM callbacks to be
>      called, yet currently the omap_device PM domain code attempts to call
>      the drivers callbacks.
>
>      To fix, use the omap_device driver_status field to check whether a
>      driver is bound to the omap_device before attempting to trigger driver
>      callbacks.
>
>      Reviewed-by: Paul Walmsley<paul@...an.com>
>      Signed-off-by: Kevin Hilman<khilman@...com>

--
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/