linux-kernel - RE: [PATCH 1/1] driver core: disable device's runtime pm during shutdown

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: <35AB98346D25394A9354ED89C4D76587228E65@039-SN1MPN1-002.039d.mgd.msft.net>
Date:	Mon, 5 Dec 2011 03:29:24 +0000
From:	Chen Peter-B29397 <B29397@...escale.com>
To:	NeilBrown <neilb@...e.de>, "Rafael J. Wysocki" <rjw@...k.pl>
CC:	Greg KH <greg@...ah.com>, "gregkh@...e.de" <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"stern@...land.harvard.edu" <stern@...land.harvard.edu>,
	"hzpeterchen@...il.com" <hzpeterchen@...il.com>,
	Igor Grinberg <grinberg@...pulab.co.il>
Subject: RE: [PATCH 1/1] driver core: disable device's runtime pm during
 shutdown

 
> 
> Hi,
>  this patches causes a problem for me.
> 
> Specifically it makes it impossible to power-down a device which uses
> twl4030
> for power control on an omap3 processor.
> 
> To perform the shutdown we need to send a command over the i2c bus.
> The relevant bus is called omap_i2c.1 and this is normally in suspend
> mode.
> When a request is sent, omap_i2c_xfer uses pm_runtime_get_sync to wake it
> up,
> performs the transfer, then calls pm_runtime_put to let it go back to
> sleep.
> 
> So it is asleep when the new pm_runtime_disable() call is made, so it
> stays
> asleep, omap_i2c_xfer cannot wake it, the transfer doesn't happen and the
> system doesn't get powered off.
> 
> So here is a device that should *not* have pm disabled at shutdown.
> 
> So I feel this fix is a little too heavy-handed.
> I don't fully understand the problem scenario described above but it
> seems to
> me that if the auto-suspend timer can fire after the hardware has been
> shut
> down, then maybe the hardware-shutdown should be disabling that timer.
> Maybe?
> 
Oh, I am sorry to cause your problem. I think it may not be easy to handle this
kinds of problem well. 

In my opinion, it is better to handle shutdown/suspend SYNC at device drivers.
Since the pm core is hard to know driver's shutdown is finished, and vice versa.

1. Driver needs to has relationship between suspend/shutdown, like usb host,
hcd needs to know downstream port's suspend, and usb core needs to know hcd's shutdown. 

2. At driver's shutdown
static void xxx_driver_shutdown(struct platform_device *pdev)
{
	if (supports_autosuspend(&pdev->dev) {
		pm_runtime_cancel_pending(&pdev->dev);
		wait_xxx_driver_suspend(pdev); /* need to sync with driver's suspend */
	}
	real_shutdown();		
}

> Suggestions?
> 
> Thanks,
> NeilBrown

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