[PATCH] USB: Spelling fixes for drivers/usb.

Here are some spelling corrections for drivers/usb.

cancelation -> cancellation
succesful -> successful
cancelation -> cancellation
decriptor -> descriptor
Initalize -> Initialize
wierd -> weird
Protocoll -> Protocol
occured -> occurred
successfull -> successful
Procesing -> Processing
devide -> divide
Isochronuous -> Isochronous
noticable -> noticeable
Basicly -> Basically
transfering -> transferring
intialize -> initialize
Incomming -> Incoming
additionnal -> additional
asume -> assume
Unfortunatly -> Unfortunately
retreive -> retrieve
tranceiver -> transceiver
Compatiblity -> Compatibility
Incorprated -> Incorporated
existance -> existence
Ununsual -> Unusual

Signed-off-by: Steven Cole <elenstev@mesatop.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit is contained in:
Steven Cole
2005-05-03 19:07:24 -06:00
committed by Greg KH
parent 7b1cbebaa7
commit 093cf723b2
24 changed files with 34 additions and 34 deletions

View File

@ -121,7 +121,7 @@ struct urb * usb_get_urb(struct urb *urb)
* describing that request to the USB subsystem. Request completion will
* be indicated later, asynchronously, by calling the completion handler.
* The three types of completion are success, error, and unlink
* (a software-induced fault, also called "request cancelation").
* (a software-induced fault, also called "request cancellation").
*
* URBs may be submitted in interrupt context.
*
@ -170,7 +170,7 @@ struct urb * usb_get_urb(struct urb *urb)
* As of Linux 2.6, all USB endpoint transfer queues support depths greater
* than one. This was previously a HCD-specific behavior, except for ISO
* transfers. Non-isochronous endpoint queues are inactive during cleanup
* after faults (transfer errors or cancelation).
* after faults (transfer errors or cancellation).
*
* Reserved Bandwidth Transfers:
*
@ -395,7 +395,7 @@ int usb_submit_urb(struct urb *urb, int mem_flags)
*
* This routine cancels an in-progress request. URBs complete only
* once per submission, and may be canceled only once per submission.
* Successful cancelation means the requests's completion handler will
* Successful cancellation means the requests's completion handler will
* be called with a status code indicating that the request has been
* canceled (rather than any other code) and will quickly be removed
* from host controller data structures.