linux-kernel - Re: [PATCH v5 5/6] ata: add ata port system PM callbacks

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]

Message-ID: <Pine.LNX.4.44L0.1112131038360.1888-100000@iolanthe.rowland.org>
Date:	Tue, 13 Dec 2011 10:47:49 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Lin Ming <ming.m.lin@...el.com>
cc:	Jeff Garzik <jgarzik@...ox.com>,
	James Bottomley <JBottomley@...allels.com>,
	Tejun Heo <tj@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-ide@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
	<linux-pm@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Huang Ying <ying.huang@...el.com>,
	Zhang Rui <rui.zhang@...el.com>
Subject: Re: [PATCH v5 5/6] ata: add ata port system PM callbacks

On Tue, 13 Dec 2011, Lin Ming wrote:

> I just realized that the ata port runtime PM status need to be updated
> after system resume.
> 
> I tried below patch.
> Unfortunately, it causes a problem that sd can't resume correctly.
> 
> During system resume, ata port is resumed first and then sd resumed.
> 
> When ata port resumed, device_resume(...) calls pm_runtime_put_sync(..),
> which causes ata port to be runtime suspended immediately.
> 
> So sd resume fails because it requires ata port to be active to handle
> start device command.
> 
> This seems a PM core's bug.
> 
> device_resume(...) should not runtime suspend the parent device, because
> its children have not resumed yet.
> 
> Alan, 
> 
> What do you think?

This appears to be the first time this problem has come up.  But it is 
a real problem.

If a child device was runtime-suspended when a system suspend began, 
then there will be nothing to prevent its parent from 
runtime-suspending as soon as it is woken up during the system resume.  
Then when the time comes to resume the child, the resume will fail 
because the parent is already back at low power.

On the other hand, there are some devices which should remain at low 
power across an entire suspend-resume cycle.  The details depend on the 
device and the platform.

This suggests that the PM core is not the right place to solve the 
problem.  One possible solution is for the subsystem or device driver 
to call pm_runtime_get_sync(dev->parent) at the start of the 
system-resume procedure and pm_runtime_put_sync(dev->parent) at the 
end.

Alan Stern

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