diff options
author | Pete Zaitcev <zaitcev@redhat.com> | 2006-06-12 23:09:39 -0400 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2006-06-21 18:04:17 -0400 |
commit | d9ac2cfc3aaf3bc37da4192d3edfa11d2ad2e96f (patch) | |
tree | 71afab7732f7acb26cb3637122a417a28741b17a | |
parent | 12e72feab5d9a23107f245b0f241a2484cbb5a4e (diff) |
[PATCH] USB: update usbmon.txt
Fix up the documentation. Apparently, I left unedited copy-paste results
in examples. Also, Alan helped me to improve the most confusing parts.
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-rw-r--r-- | Documentation/usb/usbmon.txt | 32 |
1 files changed, 18 insertions, 14 deletions
diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 63cb7edd177e..e65ec828d7aa 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt | |||
@@ -29,14 +29,13 @@ if usbmon is built into the kernel. | |||
29 | 29 | ||
30 | # mount -t debugfs none_debugs /sys/kernel/debug | 30 | # mount -t debugfs none_debugs /sys/kernel/debug |
31 | # modprobe usbmon | 31 | # modprobe usbmon |
32 | # | ||
32 | 33 | ||
33 | Verify that bus sockets are present. | 34 | Verify that bus sockets are present. |
34 | 35 | ||
35 | [root@lembas zaitcev]# ls /sys/kernel/debug/usbmon | 36 | # ls /sys/kernel/debug/usbmon |
36 | 1s 1t 2s 2t 3s 3t 4s 4t | 37 | 1s 1t 2s 2t 3s 3t 4s 4t |
37 | [root@lembas zaitcev]# | 38 | # |
38 | |||
39 | # ls /sys/kernel | ||
40 | 39 | ||
41 | 2. Find which bus connects to the desired device | 40 | 2. Find which bus connects to the desired device |
42 | 41 | ||
@@ -76,7 +75,7 @@ that the file size is not excessive for your favourite editor. | |||
76 | 75 | ||
77 | * Raw text data format | 76 | * Raw text data format |
78 | 77 | ||
79 | The '0t' type data consists of a stream of events, such as URB submission, | 78 | The '1t' type data consists of a stream of events, such as URB submission, |
80 | URB callback, submission error. Every event is a text line, which consists | 79 | URB callback, submission error. Every event is a text line, which consists |
81 | of whitespace separated words. The number of position of words may depend | 80 | of whitespace separated words. The number of position of words may depend |
82 | on the event type, but there is a set of words, common for all types. | 81 | on the event type, but there is a set of words, common for all types. |
@@ -97,20 +96,25 @@ Here is the list of words, from left to right: | |||
97 | Zi Zo Isochronous input and output | 96 | Zi Zo Isochronous input and output |
98 | Ii Io Interrupt input and output | 97 | Ii Io Interrupt input and output |
99 | Bi Bo Bulk input and output | 98 | Bi Bo Bulk input and output |
100 | Device address and Endpoint number are decimal numbers with leading zeroes | 99 | Device address and Endpoint number are 3-digit and 2-digit (respectively) |
101 | or 3 and 2 positions, correspondingly. | 100 | decimal numbers, with leading zeroes. |
102 | - URB Status. This field makes no sense for submissions, but is present | 101 | - URB Status. In most cases, this field contains a number, sometimes negative, |
103 | to help scripts with parsing. In error case, it contains the error code. | 102 | which represents a "status" field of the URB. This field makes no sense for |
104 | In case of a setup packet, it contains a Setup Tag. If scripts read a number | 103 | submissions, but is present anyway to help scripts with parsing. When an |
105 | in this field, they proceed to read Data Length. Otherwise, they read | 104 | error occurs, the field contains the error code. In case of a submission of |
106 | the setup packet before reading the Data Length. | 105 | a Control packet, this field contains a Setup Tag instead of an error code. |
106 | It is easy to tell whether the Setup Tag is present because it is never a | ||
107 | number. Thus if scripts find a number in this field, they proceed to read | ||
108 | Data Length. If they find something else, like a letter, they read the setup | ||
109 | packet before reading the Data Length. | ||
107 | - Setup packet, if present, consists of 5 words: one of each for bmRequestType, | 110 | - Setup packet, if present, consists of 5 words: one of each for bmRequestType, |
108 | bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. | 111 | bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. |
109 | These words are safe to decode if Setup Tag was 's'. Otherwise, the setup | 112 | These words are safe to decode if Setup Tag was 's'. Otherwise, the setup |
110 | packet was present, but not captured, and the fields contain filler. | 113 | packet was present, but not captured, and the fields contain filler. |
111 | - Data Length. This is the actual length in the URB. | 114 | - Data Length. For submissions, this is the requested length. For callbacks, |
115 | this is the actual length. | ||
112 | - Data tag. The usbmon may not always capture data, even if length is nonzero. | 116 | - Data tag. The usbmon may not always capture data, even if length is nonzero. |
113 | Only if tag is '=', the data words are present. | 117 | The data words are present only if this tag is '='. |
114 | - Data words follow, in big endian hexadecimal format. Notice that they are | 118 | - Data words follow, in big endian hexadecimal format. Notice that they are |
115 | not machine words, but really just a byte stream split into words to make | 119 | not machine words, but really just a byte stream split into words to make |
116 | it easier to read. Thus, the last word may contain from one to four bytes. | 120 | it easier to read. Thus, the last word may contain from one to four bytes. |