> Generally the kernel code should write the two 32-bit chunks to the > memory-mapped region in order (low dword first), and let things take > care of themselves from there. > > That's pretty much the implementation that -every- driver copies, when > they need readq/writeq to work on a 32-bit platform.
What do you mean by low dword first ? For example, the implementation in the s2io driver does: static inline u64 readq(void __iomem *addr) { u64 ret = 0; ret = readl(addr + 4); ret <<= 32; ret |= readl(addr); return ret; } static inline void writeq(u64 val, void __iomem *addr) { writel((u32) (val), addr); writel((u32) (val >> 32), (addr + 4)); } As you can see, it reads the -second- dword first (high order dword in little endian), but writes the first dword first (low order dword in little endian). If there is any logic here, it's card specific. Or is this really what PCI does when doing 64 bits accesses on a 32 bits PCI bus ? I would have expected the later (what write does) but this driver does it reverse on reads. I'm tempted to go to the simple #define readq readq for now until we clear that up. Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html