On Wednesday 28 October 2009 01:56:32 Greg KH wrote: > On Wed, Oct 28, 2009 at 12:01:57AM +0100, Michael Buesch wrote: > > On Tuesday 27 October 2009 23:38:29 Greg KH wrote: > > > On Tue, Oct 27, 2009 at 11:28:16PM +0100, Michael Buesch wrote: > > > > On Tuesday 27 October 2009 22:20:05 Greg KH wrote: > > > > > On Tue, Oct 27, 2009 at 10:00:21PM +0100, Michael Buesch wrote: > > > > > > Hi Greg, > > > > > > > > > > > > The following fields are byteswapped in lsusb on BigEndian machines: > > > > > > > > > > > > wTotalLength (Config descriptor) > > > > > > wMaxPacketSize (EP descriptor) > > > > > > > > > > How so? Can you provide the output of 'lsusb -v' so I can see it? > > > > > > > > > > > > Here's an example prototype device for which I know what the values must look like. > > > > Other devices look similiar. > > > > > > > > wTotalLength 12288 is 0x30 swapped. > > > > wMaxPacketSize 0x4000 is 0x40 swapped. > > > > 0x30 and 0x40 would be the correct values. So it certainly is a byteorder issue. > > > > > > > > This is lsusb version 0.73 (Debian Lenny stable). I didn't try a newer upstream version. > > > > > > This was fixed back in May of 2006 and should have showed up in the 0.73 > > > release. If you could, can you grab a newer version of usbutils, like > > > the upstream version, to see if it is still an issue or not? > > > > version 0.86 shows the same behavior. > > The endianness check in lsusb.c does also work correctly. > > > > The following patch will produce the correct result. > > > > However, the patch obviously is incorrect. > > I suspect that libusb (or the kernel) already swapped the values for us. > > Look at those other 16bit values like idProduct, idVendor, bcdXXX... > > Those are correctly displayed and usbutils does _not_ byteswap them. > > So I guess either libusb (or the kernel) does. > > > > > > --- usbutils-0.86.orig/lsusb.c > > +++ usbutils-0.86/lsusb.c > > @@ -41,7 +41,7 @@ > > > > #include <getopt.h> > > > > -#if (__BYTE_ORDER == __LITTLE_ENDIAN) > > +#if (__BYTE_ORDER == __LITTLE_ENDIAN) ||1 > > Somehow __BYTE_ORDER isn't getting set properly on your platform. Care > to work to figure out what it is set to? No this is not true. __BYTE_ORDER _is_ set correctly on my platform. This is a big endian platform and the patch "fixes" it. The patch basically forces le16_to_cpu() to be a no-op on all platforms. The problem is that the wTotalLength and wMaxPacketSize values are already swapped when lsusb gets them. So either libusb or the kernel swaps it to cpu-endianness. -- Greetings, Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
