And for byte endianess in readl/writel - if you'll say that on every
architecture readl/writel will store long in little endian, we can
live with it - but I do not know why. If processors supports storing
data with both endianess, why not to export this functionality to kernel
drivers? I can understand that ia32 peoples complaints about supporting
readl_be on their hardware, but PPC can do both be and le accesses very
easy...
If some ports have problem with it (specific iomapping and universal
load/store), then we can create complete set with both ioremap_[lb]e,
{read,write}[wl]_[bl]e. If there is some functionality hidden from
users, programmers get around with ugly hacks... Isn't it easier to
open the doors?
For example matroxfb have to be compatible with old XF86_SVGA on PPC
(do not have, but it is better if it cost almost nothing...). And XF86_SVGA
on PPC switched matrox into big endian mode... So have I to byteswap
all pixels and commands written to hardware and then store these data
to hardware using little-endian store? Why? Or should I break backward
compatibility for no real reason? I do not want to do that.
That's all (for now),
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/