Hello all,

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.

Regards,
-- 
Leon
--

[ message continues ]

Not sure if anyone has done work testing under big endian platforms. 
 From what I've seen in code, it looks definite little endian based 
and would need a look over regarding byte swap.

Scott
--

[ message continues ]

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:
http://www.sidebranch.com/crystalhd/

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.

Regards,
-- 
Leon
--

[ message continues ]