DOC: A couple corrections and clarifications in USB doc.

A couple of corrections and clarifications in USB
documentation.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
This commit is contained in:
Robert P. J. Day 2008-04-21 22:57:50 +00:00 committed by Jesper Juhl
parent 37679011c5
commit 838cb6aba4

View file

@ -100,8 +100,8 @@
useful documents, at the USB home page (see Resources). An excellent useful documents, at the USB home page (see Resources). An excellent
introduction to the Linux USB subsystem can be found at the USB Working introduction to the Linux USB subsystem can be found at the USB Working
Devices List (see Resources). It explains how the Linux USB subsystem is Devices List (see Resources). It explains how the Linux USB subsystem is
structured and introduces the reader to the concept of USB urbs, which structured and introduces the reader to the concept of USB urbs
are essential to USB drivers. (USB Request Blocks), which are essential to USB drivers.
</para> </para>
<para> <para>
The first thing a Linux USB driver needs to do is register itself with The first thing a Linux USB driver needs to do is register itself with
@ -162,8 +162,8 @@ static int __init usb_skel_init(void)
module_init(usb_skel_init); module_init(usb_skel_init);
</programlisting> </programlisting>
<para> <para>
When the driver is unloaded from the system, it needs to unregister When the driver is unloaded from the system, it needs to deregister
itself with the USB subsystem. This is done with the usb_unregister itself with the USB subsystem. This is done with the usb_deregister
function: function:
</para> </para>
<programlisting> <programlisting>
@ -232,7 +232,7 @@ static int skel_probe(struct usb_interface *interface,
were passed to the USB subsystem will be called from a user program trying were passed to the USB subsystem will be called from a user program trying
to talk to the device. The first function called will be open, as the to talk to the device. The first function called will be open, as the
program tries to open the device for I/O. We increment our private usage program tries to open the device for I/O. We increment our private usage
count and save off a pointer to our internal structure in the file count and save a pointer to our internal structure in the file
structure. This is done so that future calls to file operations will structure. This is done so that future calls to file operations will
enable the driver to determine which device the user is addressing. All enable the driver to determine which device the user is addressing. All
of this is done with the following code: of this is done with the following code:
@ -252,8 +252,8 @@ file->private_data = dev;
send to the device based on the size of the write urb it has created (this send to the device based on the size of the write urb it has created (this
size depends on the size of the bulk out end point that the device has). size depends on the size of the bulk out end point that the device has).
Then it copies the data from user space to kernel space, points the urb to Then it copies the data from user space to kernel space, points the urb to
the data and submits the urb to the USB subsystem. This can be shown in the data and submits the urb to the USB subsystem. This can be seen in
he following code: the following code:
</para> </para>
<programlisting> <programlisting>
/* we can only write as much as 1 urb will hold */ /* we can only write as much as 1 urb will hold */