From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pedro Lopez-Cabanillas Date: Wed, 07 May 2003 21:54:44 +0000 Subject: Re: Vosonic's X-Drive 2030 Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On Wednesday 07 May 2003 05:38, Randy.Dunlap wrote: > >> On Tuesday 06 May 2003 19:39, Pedro Lopez-Cabanillas wrote: > >>> On Tuesday 06 May 2003 13:32, Alexander K=FChn wrote: > >>> > scorpio:/etc/hotplug # cat usb.usermap > >>> > # usb module match_flags idVendor idProduct bcdDevice_lo > >>> > >>> bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol > >>> > >>> > bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info > >>> > >>> usb-storage 0x0000 0x0d7d 0x0240 0x0000 0x0000 > >>> > >>> > 0x00 0x00 0x00 0x00 =20 > >>> > 0x00 0x00 0x00000000 > >>> > >>> Can you try this? > >>> usb-storage 0x0003 0x7d0d 0x4002 0x0000 0x0000 > >>> > >>> (match_flags) ^^^^^^ > >>> (idVendor) ^^^^^^ > >>> (idProduct) ^^^^^^ > >> > >> Sorry. Seems that lsusb is not very reliable on ppc architecture > >> (bytesexual > >> problem :-). Try this instead: > >> usb-storage 0x0003 0x0d7d 0x0240 0x0000 0x00= 00 > > > > Yes, that's right. I made a patch for lsusb-endianness about 3 years > > ago, but I expect that it's lost by now...unless it's in one of the > > linux-usb email archives. > > Hm, apparently I didn't make a patch, just raised the issue and got no > resolution on it. > > Here's the beginning of the mail thread: > http://marc.theaimsgroup.com/?l=3Dlinux-usb-devel&m=98056359905969&w=3D2 > I'm not sure about this (from usbutils-0.11) lsusb.c:270 vid =3D buf[8] | (buf[9] << 8); pid =3D buf[10] | (buf[11] << 8); usbmodules.c:413 idVendor =3D buf[8] | (buf[9] << 8); idProduct =3D buf[10] | (buf[11] << 8); Both programs seem to be affected, if the above is wrong. It seems to say: = get=20 the first byte and store it on the lower half of the 16 bits word, then get= =20 the next byte and store it in the high bits, but what is doing is to store = the second byte followed by the first byte on the word. This is correct in = =20 little-endian machines, but not in big-endian. If i'm right, then the=20 following should work on both sexes: idVendor =3D buf[8] + (buf[9] * 256); idProduct =3D buf[10] + (buf[11] * 256); What do you think? But anyway, (sorry if my suspicions are wrong) the fact is that lsusb does = not =20 work in ppc, and usbmodules also can be wrong. This is more serious, becaus= e=20 usbmodules is used in hotplug scripts to find what modules to load for USB = devices if it is installed. Regards, Pedro --=20 ALSA Library Bindings for Pascal http://alsapas.alturl.com ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel