On Friday 28 April 2006 15:42, Michael Buesch wrote: > On Friday 28 April 2006 15:31, you wrote: > > On Friday 28 April 2006 15:14, Christoph Hellwig wrote: > > > On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote: > > > > I am not sure if that would be a wise idea, > > > > there is no byte ordering done in rt2500usb except for the EEPROM > > > > contents which is little endian. > > > > So when the module is used on a normal x86 platform, there won't be > > > > any big endian structures or fields. > > > > > > Well, then you'll need __le* annotation and the le*_to_cpu/cpu_to_le* > > > instead. Any new driver should be endian clean. > > > > Not exactly true for rt2570, to correctly operate with the device, no > > endian conversions should be made at all. Not to big endian and not > > to little endian. The register should be send as a regular value with the > > byteordering equal to the byteordering of the currently used CPU. > > It has been tested to send only little endian or big endian values to > > the device on all CPU's, and in all cases it meant that the device would > > not function on > > CPU's with the other byte ordering. > > I guess you are confusing something here: > MMIO access versus values in structs (for example) that > are accessed through DMA (for example).
Ah ok. I was indeed missing that point. In that case you are right, there could be some places where the __le* annotation could be used. I'll create a quick patch to do that.
pgp9JGRYGK4GM.pgp
Description: PGP signature
