has the CrystalHD driver/library been tested on big endian systems?
The (staging GIT tree) driver sources seem to use bitfields in C, is
this safe under different endianess?
I'm currently testing two BCM70012 modules on a big-endian PowerPC
system and it fails changing the clock PLL to 175 MHz. This could be a
pair of defective modules, or the wrong bits being modified.
Unfortunately, I do not have a little endian system with mini-PCIe
available to do a A-B check.
Hello Scott and others,
What parts of the code assumes little endian from what you've seen?
Now, byte swap endianess is one thing, C bitfields in combination with
it, another. I have given it a first shot here (mailer unsuitable for
sending patches), still failed on PowerPC:
May I suggest we instrument all register access functions with a
printk() of the register being written? Then I can compare little
endian access patterns with big endian, to be sure we get the
bitfields, code assumptions and byte swap correctly.