linux-kernel - Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

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:	Tue, 25 Sep 2012 11:31:20 +0300
From:	Felipe Balbi <balbi@...com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	"Poddar, Sourav" <sourav.poddar@...com>,
	gregkh@...uxfoundation.org, khilman@...com, paul@...an.com,
	tony@...mide.com, linux-kernel@...r.kernel.org, balbi@...com,
	santosh.shilimkar@...com, linux-serial@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	alan@...ux.intel.com
Subject: Re: [RFT/PATCH] serial: omap: prevent resume if device is not
 suspended.

On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 25, 2012 at 01:52:03PM +0530, Poddar, Sourav wrote:
> > Hi Greg,
> > 
> > Ping on this?
> > 
> > On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar <sourav.poddar@...com> wrote:
> > > Greg's tty-next is not booting on 2420 based N800. The failure is
> > > observed at serial init itself. The reason might be that n800 tries to
> > > resume even though it is not suspended before.
> 
> How is this happening?  I think that needs proper investigation - or if
> it's had more investigation, then the results needs to be included in
> the commit description so that everyone can understand the issue here.
> 
> We should not be resuming a device which hasn't been suspended.  Maybe
> the runtime PM enable sequence is wrong, and that's what should be fixed
> instead?  
> 
> This sequence in the probe() function:
> 
>         pm_runtime_irq_safe(&pdev->dev);
>         pm_runtime_enable(&pdev->dev);
>         pm_runtime_get_sync(&pdev->dev);
> 
> would enable runtime PM while the s/w state indicates that it's disabled,
> and then that pm_runtime_get_sync() will want to resume the device.  See
> the section "5. Runtime PM Initialization, Device Probing and Removal"
> in Documentation/power/runtime_pm.txt, specifically the second paragraph
> of that section.

that was tested. It worked in pandaboard but didn't work on beagleboard
XM. Sourav tried to start a discussion about that, but it simply died...

In any case, pm_runtime_get_sync() in probe will always call
runtime_resume callback, right ?

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)