aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorolecom@mail.ru <olecom@mail.ru>2006-06-26 13:05:40 -0400
committerAdrian Bunk <bunk@stusta.de>2006-06-26 13:05:40 -0400
commit2e2d0dcc1bd7ca7c26ea5e29efb7f34bbd564f1c (patch)
tree425d5bbf1a5fac50cfba1d974651c786af940376
parentf274afc9933e5fd5987a4a2a5f02687958f8ba65 (diff)
typo fixes
Signed-off-by: Adrian Bunk <bunk@stusta.de>
-rw-r--r--Documentation/DocBook/kernel-locking.tmpl2
-rw-r--r--Documentation/driver-model/overview.txt2
2 files changed, 2 insertions, 2 deletions
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 158ffe9bfade..644c3884fab9 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -1590,7 +1590,7 @@ the amount of locking which needs to be done.
1590 <para> 1590 <para>
1591 Our final dilemma is this: when can we actually destroy the 1591 Our final dilemma is this: when can we actually destroy the
1592 removed element? Remember, a reader might be stepping through 1592 removed element? Remember, a reader might be stepping through
1593 this element in the list right now: it we free this element and 1593 this element in the list right now: if we free this element and
1594 the <symbol>next</symbol> pointer changes, the reader will jump 1594 the <symbol>next</symbol> pointer changes, the reader will jump
1595 off into garbage and crash. We need to wait until we know that 1595 off into garbage and crash. We need to wait until we know that
1596 all the readers who were traversing the list when we deleted the 1596 all the readers who were traversing the list when we deleted the
diff --git a/Documentation/driver-model/overview.txt b/Documentation/driver-model/overview.txt
index ac4a7a737e43..2050c9ffc629 100644
--- a/Documentation/driver-model/overview.txt
+++ b/Documentation/driver-model/overview.txt
@@ -18,7 +18,7 @@ Traditional driver models implemented some sort of tree-like structure
18(sometimes just a list) for the devices they control. There wasn't any 18(sometimes just a list) for the devices they control. There wasn't any
19uniformity across the different bus types. 19uniformity across the different bus types.
20 20
21The current driver model provides a comon, uniform data model for describing 21The current driver model provides a common, uniform data model for describing
22a bus and the devices that can appear under the bus. The unified bus 22a bus and the devices that can appear under the bus. The unified bus
23model includes a set of common attributes which all busses carry, and a set 23model includes a set of common attributes which all busses carry, and a set
24of common callbacks, such as device discovery during bus probing, bus 24of common callbacks, such as device discovery during bus probing, bus