Commit 9a9fafb8 authored by Phil Endecott's avatar Phil Endecott Committed by Greg Kroah-Hartman

USB: fix comment about endianness of descriptors

This patch fixes a comment and clarifies the documentation about the
endianness of descriptors. The current policy is that descriptors will
be little-endian at the API even on big-endian systems; however the
/proc/bus/usb API predates this policy and presents descriptors with
some multibyte fields byte-swapped.
Signed-off-by: default avatarPhil Endecott <usb_endian_patch@chezphil.org>
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
parent c33ba392
...@@ -49,8 +49,10 @@ it and 002/048 sometime later. ...@@ -49,8 +49,10 @@ it and 002/048 sometime later.
These files can be read as binary data. The binary data consists These files can be read as binary data. The binary data consists
of first the device descriptor, then the descriptors for each of first the device descriptor, then the descriptors for each
configuration of the device. That information is also shown in configuration of the device. Multi-byte fields in the device and
text form by the /proc/bus/usb/devices file, described later. configuration descriptors, but not other descriptors, are converted
to host endianness by the kernel. This information is also shown
in text form by the /proc/bus/usb/devices file, described later.
These files may also be used to write user-level drivers for the USB These files may also be used to write user-level drivers for the USB
devices. You would open the /proc/bus/usb/BBB/DDD file read/write, devices. You would open the /proc/bus/usb/BBB/DDD file read/write,
......
...@@ -158,8 +158,12 @@ struct usb_ctrlrequest { ...@@ -158,8 +158,12 @@ struct usb_ctrlrequest {
* (rarely) accepted by SET_DESCRIPTOR. * (rarely) accepted by SET_DESCRIPTOR.
* *
* Note that all multi-byte values here are encoded in little endian * Note that all multi-byte values here are encoded in little endian
* byte order "on the wire". But when exposed through Linux-USB APIs, * byte order "on the wire". Within the kernel and when exposed
* they've been converted to cpu byte order. * through the Linux-USB APIs, they are not converted to cpu byte
* order; it is the responsibility of the client code to do this.
* The single exception is when device and configuration descriptors (but
* not other descriptors) are read from usbfs (i.e. /proc/bus/usb/BBB/DDD);
* in this case the fields are converted to host endianness by the kernel.
*/ */
/* /*
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment