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



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to