On Sat, 2005-04-02 at 21:40 -0600, James Bottomley wrote: > Actually, ioread8be is unnecessary, but I was planning to add > ioread16/ioread32 and iowritexx be on be variants (equivalent to > _raw_readw et al.) > > After all, the driver must know the card is BE, so the routines that > make use of the feature are easily coded into the card, so there's no > real need to add it to the iomem cookie. > > Did anyone have a preference for the API? I was thinking > ioread32_native, but ioread32be is fine too. I think we want "be" since obviously, the "ioread32" one is "le", that makes sense to provide both and let the implementation bother with what has to swap or not. With "native", x86 would do what ? swap or not swap ? unclear ... with "be", at least it's clear. The problem ? Hehe, well ... there is at least one little problem: The way iomap "fixes" the issue of mem vs. io space in a driver could have been used to also fix le vs. be issues. For example, an USB OHCI controller is normally little endian. But some too-stupid-for-words HW folks tried to be too smart on a number of embedded chips, and put a big endian version of it. Thus the driver ends up having to support both. Most embedded vendors just butcher the driver with #ifdef's which is fine by me ... until you end up having _also_ a PCI bus with an EHCI/OHCI pair on it on the same board... then you are toast. But, I wouldn't bother too much about this case. The driver has other issues than just IO to deal with (the DMA data structures in memory are also endian- swapped) so I suppose the entire driver need to be somewhat #included from a wrapper an compiled twice for different endians to get that right... Ben. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
