diff options
| author | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2011-04-18 17:12:14 +0100 |
|---|---|---|
| committer | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2011-04-18 17:12:14 +0100 |
| commit | fac56c2df51bc29b07b3c2dcfabf32a015a0522c (patch) | |
| tree | 1ff5d84ecf4ea0bcbd42e2ef9624b5ade3810890 /Documentation/power/devices.txt | |
| parent | 6caa15d0b84d2ea688fd31f4f172c8353463e109 (diff) | |
| parent | a6360dd37e1a144ed11e6548371bade559a1e4df (diff) | |
Merge commit 'v2.6.39-rc3' into for-2.6.39
Diffstat (limited to 'Documentation/power/devices.txt')
| -rw-r--r-- | Documentation/power/devices.txt | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index f023ba6bba6..1971bcf48a6 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -367,7 +367,7 @@ Drivers need to be able to handle hardware which has been reset since the suspend methods were called, for example by complete reinitialization. This may be the hardest part, and the one most protected by NDA'd documents and chip errata. It's simplest if the hardware state hasn't changed since -the suspend was carried out, but that can't be guaranteed (in fact, it ususally +the suspend was carried out, but that can't be guaranteed (in fact, it usually is not the case). Drivers must also be prepared to notice that the device has been removed |