diff options
| author | olecom@mail.ru <olecom@mail.ru> | 2006-06-26 13:05:40 -0400 |
|---|---|---|
| committer | Adrian Bunk <bunk@stusta.de> | 2006-06-26 13:05:40 -0400 |
| commit | 2e2d0dcc1bd7ca7c26ea5e29efb7f34bbd564f1c (patch) | |
| tree | 425d5bbf1a5fac50cfba1d974651c786af940376 | |
| parent | f274afc9933e5fd5987a4a2a5f02687958f8ba65 (diff) | |
typo fixes
Signed-off-by: Adrian Bunk <bunk@stusta.de>
| -rw-r--r-- | Documentation/DocBook/kernel-locking.tmpl | 2 | ||||
| -rw-r--r-- | Documentation/driver-model/overview.txt | 2 |
2 files changed, 2 insertions, 2 deletions
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 158ffe9bfa..644c3884fa 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 ac4a7a737e..2050c9ffc6 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 |
| 19 | uniformity across the different bus types. | 19 | uniformity across the different bus types. |
| 20 | 20 | ||
| 21 | The current driver model provides a comon, uniform data model for describing | 21 | The current driver model provides a common, uniform data model for describing |
| 22 | a bus and the devices that can appear under the bus. The unified bus | 22 | a bus and the devices that can appear under the bus. The unified bus |
| 23 | model includes a set of common attributes which all busses carry, and a set | 23 | model includes a set of common attributes which all busses carry, and a set |
| 24 | of common callbacks, such as device discovery during bus probing, bus | 24 | of common callbacks, such as device discovery during bus probing, bus |
