It would be good to get a copy of 'uname -a' in this case, just to be certain.
Someone should also verify that USB_VENDOR_ID_GENESYS isn't byte-swapped or something silly like that... Matt On Sat, Jan 15, 2005 at 02:55:03PM -0500, Alan Stern wrote: > On Sat, 15 Jan 2005, Jan De Luyck wrote: > > > > Ah, you must be talking about the le16_to_cpu() addition. That wasn't > > > part of the increased-delay patch; it was in a separate changeset. > > > > > > The line now reads: > > > > > > if (le16_to_cpu(us->pusb_dev->descriptor.idVendor) == > > > USB_VENDOR_ID_GENESYS) > > > > > > The le16_to_cpu() part _is_ necessary. The value it's looking at, the > > > descriptor.idVendor, used to be stored in native byte order but now is > > > stored in little-endian order. If you're using an x86 system, of course, > > > there won't be any difference. > > > > Yes, it's that that i meant. Strangely enough, when i removed that part it > > worked again..... Is there some extra delay added by that? > > It depends on the architecture of your computer. For architectures like > Intel's, which are little-endian, there is no delay at all because the > conversion from little-endian to native format doesn't have to do > anything. For big-endian architectures there will be an added delay too > small to measure or calculate, perhaps 10 ns or less. That's certainly > not enough to affect the operation. > > I can deduce that you're using a little-endian processor; otherwise when > you took out the conversion the code would stop working. It's hard to say > why your system failed originally; it was probably something unrelated to > this. > > Alan Stern > > _______________________________________________ > Usb-storage mailing list > [EMAIL PROTECTED] > https://lists.one-eyed-alien.net/mailman/listinfo/usb-storage -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998
pgpE8vJcjDBSg.pgp
Description: PGP signature
