CrystalHD driver safe on big endian systems?

[Leon Woestenberg]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Scott D. Davilla]

>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.

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

[Leon Woestenberg]

Hello Scott and others,

On Mon, Mar 22, 2010 at 4:53 AM, Scott D. Davilla <dav...@4pi.com> wrote:
>
> <..> From what I've seen in code, it looks definite little endian based and would need

> a look over regarding byte swap.
>

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.