Hi, David Brownell wrote: > On Tuesday 11 April 2006 8:56 am, Andre' Draszik wrote: >> I am working on an OHCI driver for a SOC that expects all but control >> transfers to the root hub to be big endian.
Now, after having more insight into the linux USB code, the reason is of course, the virtual root hub 'transfers' are handled by source code which naturally doesn't suffer of endianess problems. >> Also, it swaps incoming data. > > Sounds buggy as all get-out. What policy could it use to swap incoming > data bytes? It can't assume all data bytes are 16-bit integers, because > some device protocols use 32-bit integers. I finally found out that all transfers are always swapped by 32 bits. > you'll have to get the details and provide a workaround. I'm thinking for > example of drivers/mmc/at91_mci.c which works around a silicon bug by > doing a swab32() on all ingoing and outgoing data buffers. That's what I wanted to do. As it turns out, many drivers allocate buffers just large enough to hold the data to be sent/expected, which is quite seldom a multiple of 4. Therefore, I would touch invalid memory addresses sooner or later when just ignoring this fact and swapping bytes around as I need to. As far as I can see I have two possibilies: (a) review/rewrite every driver I want to work, or (b) implement quite some code to allocate a new chunk of memory and copy data around in case the buffer provided by a driver is not a multiple of 4. The copying doesn't worry me as much, since I have to swab32() all bytes anyway. But kmalloc()ing/kfree()ing a buffer for every transfer seems to be quite expensive and I also don't have memory to waste... Just stealing urb->transfer_buffer etc. doesn't work, because many drivers let this just be a pointer into some other memory buffer. >From a performance point of view, a) would be better, but (b) would provide more flexibility... Did I miss something? Are there other ideas? Greets, Andre' PS: I also guess, a patch to require every usb driver in the official kernel tree to provide buffers w/ size % 4 == 0 would never be accepted. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
