Docs: usb: Code and text updates from usb-skeleton

index b43e1ce49f0e..1fd7bf1dbdb0 100644
@@ -218,7 +218,7 @@ do very much processing at that time. Our implementation of
 ``skel_write_bulk_callback`` merely reports if the urb was completed
 successfully or not and then returns.
 
-The read function works a bit differently from the write function in
+This read function works a bit differently from the write function in
 that we do not use an urb to transfer data from the device to the
 driver. Instead we call the :c:func:`usb_bulk_msg` function, which can be used
 to send or receive data from a device without having to create urbs and

@@ -229,25 +229,25 @@ receiving any data from the device, the function will fail and return an
 error message. This can be shown with the following code::
 
     /* do an immediate bulk read to get data from the device */
-    retval = usb_bulk_msg (skel->dev,
-			   usb_rcvbulkpipe (skel->dev,
-			   skel->bulk_in_endpointAddr),
-			   skel->bulk_in_buffer,
-			   skel->bulk_in_size,
-			   &count, 5000);
+    retval = usb_bulk_msg(dev->udev,
+			 usb_rcvbulkpipe (dev->udev,
+			 dev->bulk_in_endpointAddr),
+			 dev->bulk_in_buffer,
+			 dev->bulk_in_size,
+			 &len, 5000);
     /* if the read was successful, copy the data to user space */
     if (!retval) {
-	    if (copy_to_user (buffer, skel->bulk_in_buffer, count))
+	    if (copy_to_user (buffer, dev->bulk_in_buffer, len))
 		    retval = -EFAULT;
 	    else
-		    retval = count;
+		    retval = len;
     }
 
 
 The :c:func:`usb_bulk_msg` function can be very useful for doing single reads
 or writes to a device; however, if you need to read or write constantly to
 a device, it is recommended to set up your own urbs and submit them to
-the USB subsystem.
+the USB subsystem. The template uses urbs for read and write.
 
 When the user program releases the file handle that it has been using to
 talk to the device, the release function in the driver is called. In

index 1fd7bf1dbdb0..c336dfd82426 100644
@@ -254,8 +254,8 @@ talk to the device, the release function in the driver is called. In
 this function we decrement our private usage count and wait for possible
 pending writes::
 
-    /* decrement our usage count for the device */
-    --skel->open_count;
+    /* decrement the count on our device */
+    kref_put(&dev->kref, skel_delete);
 
 
 One of the more difficult problems that USB drivers must be able to

index c336dfd82426..6c487ac5eab2 100644
@@ -266,15 +266,15 @@ notify the user-space programs that the device is no longer there. The
 following code (function ``skel_delete``) is an example of how to do
 this::
 
-    static inline void skel_delete (struct usb_skel *dev)
+    static void skel_delete(struct kref *kref)
     {
-	kfree (dev->bulk_in_buffer);
-	if (dev->bulk_out_buffer != NULL)
-	    usb_free_coherent (dev->udev, dev->bulk_out_size,
-		dev->bulk_out_buffer,
-		dev->write_urb->transfer_dma);
-	usb_free_urb (dev->write_urb);
-	kfree (dev);
+	struct usb_skel *dev = to_skel_dev(kref);
+
+	usb_free_urb(dev->bulk_in_urb);
+	usb_put_intf(dev->interface);
+	usb_put_dev(dev->udev);
+	kfree(dev->bulk_in_buffer);
+	kfree(dev);
     }
 
 

index 6c487ac5eab2..1968cf5c55f6 100644
@@ -278,15 +278,13 @@ this::
     }
 
 
-If a program currently has an open handle to the device, we reset the
-flag ``device_present``. For every read, write, release and other
+If the driver probed the device successfully, the flag ``disconnected``
+is initialized and set to false. For every read, write and other
 functions that expect a device to be present, the driver first checks
-this flag to see if the device is still present. If not, it releases
-that the device has disappeared, and a ``-ENODEV`` error is returned to the
-user-space program. When the release function is eventually called, it
-determines if there is no device and if not, it does the cleanup that
-the ``skel_disconnect`` function normally does if there are no open files
-on the device (see Listing 5).
+this flag to see if the device is still present. If not, a ``-ENODEV``
+error is returned to the user-space program. When the device is
+disconnected, the ``skel_disconnect`` function is called. It sets
+``disconnected`` to true and cleans up.
 
 Isochronous Data
 ================

index 1968cf5c55f6..9f4181cafc41 100644
@@ -220,10 +220,10 @@ successfully or not and then returns.
 
 This read function works a bit differently from the write function in
 that we do not use an urb to transfer data from the device to the
-driver. Instead we call the :c:func:`usb_bulk_msg` function, which can be used
+driver. Instead we call usb_bulk_msg(), which can be used
 to send or receive data from a device without having to create urbs and
-handle urb completion callback functions. We call the :c:func:`usb_bulk_msg`
-function, giving it a buffer into which to place any data received from
+handle urb completion callback functions. We call usb_bulk_msg(),
+giving it a buffer into which to place any data received from
 the device and a timeout value. If the timeout period expires without
 receiving any data from the device, the function will fail and return an
 error message. This can be shown with the following code::

@@ -244,13 +244,13 @@ error message. This can be shown with the following code::
     }
 
 
-The :c:func:`usb_bulk_msg` function can be very useful for doing single reads
+usb_bulk_msg() can be very useful for doing single reads
 or writes to a device; however, if you need to read or write constantly to
 a device, it is recommended to set up your own urbs and submit them to
 the USB subsystem. The template uses urbs for read and write.
 
 When the user program releases the file handle that it has been using to
-talk to the device, the release function in the driver is called. In
+talk to the device, skel_release() in the driver is called. In
 this function we decrement our private usage count and wait for possible
 pending writes::
 

@@ -262,9 +262,8 @@ One of the more difficult problems that USB drivers must be able to
 handle smoothly is the fact that the USB device may be removed from the
 system at any point in time, even if a program is currently talking to
 it. It needs to be able to shut down any current reads and writes and
-notify the user-space programs that the device is no longer there. The
-following code (function ``skel_delete``) is an example of how to do
-this::
+notify the user-space programs that the device is no longer there.
+skel_delete() is an example of how to do this::
 
     static void skel_delete(struct kref *kref)
     {

@@ -283,8 +282,8 @@ is initialized and set to false. For every read, write and other
 functions that expect a device to be present, the driver first checks
 this flag to see if the device is still present. If not, a ``-ENODEV``
 error is returned to the user-space program. When the device is
-disconnected, the ``skel_disconnect`` function is called. It sets
-``disconnected`` to true and cleans up.
+disconnected, skel_disconnect() is called. It sets ``disconnected``
+to true and cleans up.
 
 Isochronous Data
 ================