Bitfield endianess not handled correctly

Patch fixing byte swap for xscale be platforms.

Signed-off-by: R. van Brenk <rudger@hopling.com>

What platform are you running? Is the hardware attached in Big Endian or Little Endian mode?

Replying to mentor:

What platform are you running? Is the hardware attached in Big Endian or Little Endian mode?

As the subject says Xscale BE so Big Endian! It's an ADI phronghorn metro board with an ixp425 in bigendian mode and Senao NMP8601 radio card (AR5414 mac).

Sorry, I'll be more clear, is the IO bus connected in BE or LE mode?

OK. So the problem here is that you have a processor running in Big Endian mode, but the hardware/bus attached in Little Endian mode. Fixing this simply requires adding the relevant byte swapping to the register read macros. However, I do not know how to detect which mode hardware is attached in.

Hmm I found this in some old old madwifi mailing list from 2005.

From: Mark Rakes <mrakes@ma...>
Re: [Madwifi-devel] Re: Hi, Everyone. I find a interesting issue about "HAL status 3" error, " ath0: hardware error; reseting "error and "-DAH_BYTE_ORDER=AH_BIG_ENDIAN" option.  
2005-01-29 00:17

be aware that the patches Steffen and I were discussing were specific
to ixp42x-xscale target (which needs readl/writel to access pci space).
the patch also swaps which address range is "bswapped" because both the
xscale hardware and the atheros hardware was doing the le-to-be swap in
hardware, thus making the data little-endian again.

hope this helps.
-mark

I'm not exactly sure what is meant here, and if this is true is there any way to stop the atheros mac/hal swapping bytes?

Hmm. Today I found that the previous patch doesn't solve anything and does make no difference. So we can skip that, and I still don't know why I concluded it fixed my problems.

Ok looking more at the problem i found out my arm-linux-gcc version 3.4.4 is having problems decoding the bitmasks in struct ar5212_desc (the file sample.h). This is were all the strange values come from...

I've attached a patch which will create define macros in hal/ah_desc.h and the patch will remove usage of the struct ar5212_desc in sample.c

I'm sorry the patch is looking a bit ugly but there is no time left since I'm not having vary much time next week to clean up things.

Note: The patch isn't tested fully on LE systems, also the new rate algorithm minstrel is using these bitmasks and thus will also fail.

Patch fixing bitmask usage of struct ar5212_desc in sample.c

Signed-off-by: R. van Brenk <rudger@hopling.com>

What is the status of GCC on ARM? Does a later version of GCC work properly?

Hmmm, the bitfields ar listed as uint32_t, so they should work as unsigned values... However, a common problem seems to be confusion over whether bit fields are signed or unsigned. Maybe you could try with -funsigned-bitfields?

xscale-be-descriptor-swap.patch is unacceptable because it changes non-free HAL files.

Replying to mentor:

What is the status of GCC on ARM? Does a later version of GCC work properly?

I have tried a hacked up gcc-3.4.1 I've been using for years, as well as 2 revs of gcc used by Gentoo - 3.4.4 and 4.1.2. They all show the same behavior, which is consistent with what I would expect from a big endian platform. It's possible that the creator of this ticket has a broken gcc, or he might just be running on a big endian platform.

The problem is that the field order within the bitfield is declared correctly for little endian platforms, but not big endian ones. The structure needs to be redefined with this in mind, using <asm/byteorder.h> and LITTLE_ENDIAN_BITFIELD / BIG_ENDIAN_BITFIELD ifdef clauses. (Those macro names have two leading underscores each, but it looks like the wiki markup eats them.)

Replying to Mark Glines <mark@glines.org>:

The problem is that the field order within the bitfield is declared correctly for little endian platforms, but not big endian ones. The structure needs to be redefined with this in mind, using <asm/byteorder.h> and LITTLE_ENDIAN_BITFIELD / BIG_ENDIAN_BITFIELD ifdef clauses. (Those macro names have two leading underscores each, but it looks like the wiki markup eats them.)

I also strongly suspect this issue has already been fixed, in svn r2360. rudger@hopling.com, would you mind retesting?

Mark

Spiffy. This means I can fix support without having to use icky macros.

svn r2360 indeed fixes the problem.

Closing, per feedback.