[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141028084745.GY12379@n2100.arm.linux.org.uk>
Date: Tue, 28 Oct 2014 08:47:46 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Johan Hovold <johan@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Felipe Balbi <balbi@...com>,
Alessandro Zummo <a.zummo@...ertech.it>,
Tony Lindgren <tony@...mide.com>,
BenoƮt Cousson <bcousson@...libre.com>,
Lokesh Vutla <lokeshvutla@...com>,
Guenter Roeck <linux@...ck-us.net>, nsekhar@...com,
t-kristo@...com, j-keerthy@...com, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On Tue, Oct 28, 2014 at 09:16:16AM +0100, Johan Hovold wrote:
> It looks like we're soon to be having power-off call chains, with
> configurable priorities, to shut of various parts of the hardware
I really hope that they *don't* get used like that. I guess this is
what happens when people don't read the code before they decide to
implement something.
All the reboot/power off/halt methods already call into the driver model,
and the driver model then iterates over all bound drivers calling their
"shutdown" method. So, today, as it has been for years, all device
drivers are notified of system power off.
That's where most device drivers should be cleanly stopping their
hardware.
The only thing which is left is the actual hardware triggering of the
action, and that should be what's done via the notifier.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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