Hi Jonas, > I guess this means that the lea32_to_cpu() and simular calls would not > be safe to use on all architectures, since we have big endian systems > connected as both big endian and little endian. Agreed. > You are right that the specification never mentions how the data bus > should be wired. If it did, then it could definitely be argued that > our boards are wired up "incorrectly". I dug some more, and it turns out its documented here: http://www.nxp.com/cgi-bin/faq/faq.pl?query=q&id=309&gid=35&fid=2 Quote: "Q: Is the input data bus of the ISP1760 big endian or little endian? A: The ISP1760/1 is a little Endian Device." It would have been nice if NXP put that sentence somewhere in the official documentation:) > I think it would be possible to modify the driver so that it can take > more parameters, instead of a patch which relies on the endianess of > the CPU. It would then be possible to specify in the board setup that > the data bus is 16-bit and big endian. > > The patch could be done in such a way so that it doesn't effect other > boards, which will initalise the new fields as zero. For example, add > a "bool swap_databus_endianess" field which we can set to "true" in > our board setups. > > It can either be solved with if-statements in the write functions > (which will add some overhead for all systems), or we can have > multiple versions of the write functions, check the new field once and > store the function pointer to the correct write function when the > driver is set up. I'd vote for the separate, broken out write/read functions. We also should be able to use the existing "devflags" field of isp1760_hcd, ie just add a new ISP1760_FLAG_BUS_BIG_ENDIAN define. For boards without Open Firmware support, perhaps we could read a known register (eg the ID register) in 32-bit little endian mode and use that data to determine how the bus is wired. That could make it so that the user wouldn't have to specify how the bus was wired - the driver could dynamically determine it at runtime. I'll go ahead and generate an initial patch for review. Best, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
