mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-30 19:51:31 -04:00
Fix typos in Documentation/: 'S'
This patch fixes typos in various Documentation txts. The patch addresses some words starting with the letter 'S'. Signed-off-by: Matt LaPlante <[email protected]> Acked-by: Alan Cox <[email protected]> Acked-by: Randy Dunlap <[email protected]> Signed-off-by: Adrian Bunk <[email protected]>
This commit is contained in:
Matt LaPlante
Adrian Bunk
parent
d6bc8ac9e1
commit
53cb47268e
30 changed files with 72 additions and 71 deletions
|
|
@ -4,7 +4,7 @@ Introduction
|
|||
-------------------------
|
||||
The aacraid driver adds support for Adaptec (http://www.adaptec.com)
|
||||
RAID controllers. This is a major rewrite from the original
|
||||
Adaptec supplied driver. It has signficantly cleaned up both the code
|
||||
Adaptec supplied driver. It has significantly cleaned up both the code
|
||||
and the running binary size (the module is less than half the size of
|
||||
the original).
|
||||
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ The following information is available in this file:
|
|||
an SDTR with an offset of 0 to be sure the target
|
||||
knows we are async. This works around a firmware defect
|
||||
in the Quantum Atlas 10K.
|
||||
- Implement controller susupend and resume.
|
||||
- Implement controller suspend and resume.
|
||||
- Clear PCI error state during driver attach so that we
|
||||
don't disable memory mapped I/O due to a stray write
|
||||
by some other driver probe that occurred before we
|
||||
|
|
|
|||
|
|
@ -241,7 +241,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
|
|||
that instead of dumping the register contents on the card, this
|
||||
option dumps the contents of the sequencer program RAM. This gives
|
||||
the ability to verify that the instructions downloaded to the
|
||||
card's sequencer are indeed what they are suppossed to be. Again,
|
||||
card's sequencer are indeed what they are supposed to be. Again,
|
||||
unless you have documentation to tell you how to interpret these
|
||||
numbers, then it is totally useless.
|
||||
|
||||
|
|
|
|||
|
|
@ -309,9 +309,9 @@
|
|||
2.6 Abort & Reset Commands
|
||||
--------------------------
|
||||
These are implemented with busy waiting for interrupt to arrive.
|
||||
ibmmca_reset() and ibmmca_abort() do not work sufficently well
|
||||
up to now and need still a lot of development work. But, this seems
|
||||
to be even a problem with other SCSI-low level drivers, too. However,
|
||||
ibmmca_reset() and ibmmca_abort() do not work sufficiently well
|
||||
up to now and need still a lot of development work. This seems
|
||||
to be a problem with other low-level SCSI drivers too, however
|
||||
this should be no excuse.
|
||||
|
||||
2.7 Disk Geometry
|
||||
|
|
@ -684,8 +684,8 @@
|
|||
not like sending commands to non-existing SCSI-devices and will react
|
||||
with a command error as a sign of protest. While this error is not
|
||||
present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI
|
||||
Adapters. Therefore, I implemented a workarround to forgive those
|
||||
adapters their protests, but it is marked up in the statisctis, so
|
||||
Adapters. Therefore, I implemented a workaround to forgive those
|
||||
adapters their protests, but it is marked up in the statistics, so
|
||||
after a successful boot, you can see in /proc/scsi/ibmmca/<host_number>
|
||||
how often the command errors have been forgiven to the SCSI-subsystem.
|
||||
If the number is bigger than 0, you have a SCSI subsystem of older
|
||||
|
|
@ -778,15 +778,15 @@
|
|||
not accept this, as they stick quite near to ANSI-SCSI and report
|
||||
a COMMAND_ERROR message which causes the driver to panic. The main
|
||||
problem was located around the INQUIRY command. Now, for all the
|
||||
mentioned commands, the buffersize, sent to the adapter is at
|
||||
mentioned commands, the buffersize sent to the adapter is at
|
||||
maximum 255 which seems to be a quite reasonable solution.
|
||||
TEST_UNIT_READY gets a buffersize of 0 to make sure, that no
|
||||
TEST_UNIT_READY gets a buffersize of 0 to make sure that no
|
||||
data is transferred in order to avoid any possible command failure.
|
||||
2) On unsuccessful TEST_UNIT_READY, the midlevel-driver has to send
|
||||
a REQUEST_SENSE in order to see, where the problem is located. This
|
||||
2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send
|
||||
a REQUEST_SENSE in order to see where the problem is located. This
|
||||
REQUEST_SENSE may have various length in its answer-buffer. IBM
|
||||
SCSI-subsystems report a command failure, if the returned buffersize
|
||||
is different from the sent buffersize, but this can be supressed by
|
||||
SCSI-subsystems report a command failure if the returned buffersize
|
||||
is different from the sent buffersize, but this can be suppressed by
|
||||
a special bit, which is now done and problems seem to be solved.
|
||||
2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on
|
||||
2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes.
|
||||
|
|
@ -1156,7 +1156,7 @@
|
|||
Guide) what has to be done for reset, we still share the bad shape of
|
||||
the reset functions with all other low level SCSI-drivers.
|
||||
Astonishingly, reset works in most cases quite ok, but the harddisks
|
||||
won't run in synchonous mode anymore after a reset, until you reboot.
|
||||
won't run in synchronous mode anymore after a reset, until you reboot.
|
||||
Q: Why does my XXX w/Cache adapter not use read-prefetch?
|
||||
A: Ok, that is not completely possible. If a cache is present, the
|
||||
adapter tries to use it internally. Explicitly, one can use the cache
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Written by Gerard Roudier <[email protected]>
|
|||
15. SCSI problem troubleshooting
|
||||
15.1 Problem tracking
|
||||
15.2 Understanding hardware error reports
|
||||
16. Synchonous transfer negotiation tables
|
||||
16. Synchronous transfer negotiation tables
|
||||
16.1 Synchronous timings for 53C875 and 53C860 Ultra-SCSI controllers
|
||||
16.2 Synchronous timings for fast SCSI-2 53C8XX controllers
|
||||
17. Serial NVRAM support (by Richard Waltham)
|
||||
|
|
@ -1382,7 +1382,7 @@ SCSI standards, chip cores functionnals and internal driver data structures.
|
|||
You are not required to decode and understand them, unless you want to help
|
||||
maintain the driver code.
|
||||
|
||||
16. Synchonous transfer negotiation tables
|
||||
16. Synchronous transfer negotiation tables
|
||||
|
||||
Tables below have been created by calling the routine the driver uses
|
||||
for synchronisation negotiation timing calculation and chip setting.
|
||||
|
|
|
|||
|
|
@ -369,7 +369,7 @@ MTSETDRVBUFFER
|
|||
the device dependent address. It is recommended to set
|
||||
this flag unless there are tapes using the device
|
||||
dependent (from the old times) (global)
|
||||
MT_ST_SYSV sets the SYSV sematics (mode)
|
||||
MT_ST_SYSV sets the SYSV semantics (mode)
|
||||
MT_ST_NOWAIT enables immediate mode (i.e., don't wait for
|
||||
the command to finish) for some commands (e.g., rewind)
|
||||
MT_ST_DEBUGGING debugging (global; debugging must be
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ under Linux is contained in 2 files named sym_glue.h and sym_glue.c.
|
|||
Other drivers files are intended not to depend on the Operating System
|
||||
on which the driver is used.
|
||||
|
||||
The history of this driver can be summerized as follows:
|
||||
The history of this driver can be summarized as follows:
|
||||
|
||||
1993: ncr driver written for 386bsd and FreeBSD by:
|
||||
Wolfgang Stanglmeier <[email protected]>
|
||||
|
|
|
|||
Loading…
Reference in a new issue